本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
开发具有专用吞吐量的增强型扇出消费者
在 Amazon Kinesis Data Streams 中,可以构建使用增强型扇出功能的消费端。此功能允许使用者从每个分片每秒吞吐量高达 2 MB 的数据流中接收记录。此为专用吞吐量,这意味着,使用增强型扇出功能的消费端不必与接收流中数据的其他消费端争夺。Kinesis Data Streams 将流中的数据记录推送到使用增强型扇出功能的消费端。因此,这些消费端无需轮询数据。
重要
您可以为每个流注册多达 20 个消费端,以便使用增强型扇出功能。
下图显示的是增强型扇出功能架构。如果使用 2.0 版或更高版本的 Amazon Kinesis Client Library(KCL)构建消费端,则 KCL 会将消费端设置为使用增强型扇出功能接收来自流的所有分片的数据。如果使用 API 构建使用增强型扇出功能的消费端,则可订阅单个分片。

此图显示以下内容:
-
一个具有两个分片的流。
-
使用增强型扇出功能接收流中数据的两个消费端:消费端 X 和消费端 Y。这两个消费端均已订阅流的所有分片和所有记录。如果使用 2.0 版或更高版本的 KCL 构建消费端,则 KCL 将自动为消费端订阅流的所有分片。另一方面,如果使用 API 构建消费端,则可订阅单个分片。
-
表示消费端用于接收流中数据的增强型扇出功能管道的箭头。增强的扇出管道为每个分片提供最多 2 MB/sec 个数据,与任何其他管道或使用者总数无关。
共享吞吐量使用者和增强型扇出消费者之间的区别
下表将默认共享吞吐量使用者与增强型扇出使用者进行了比较。消息传播延迟定义为使用负载调度(如和)发送的有效负载通过消耗负载的负载 APIs (如PutRecord
和PutRecords
)到达使用者应用程序所花费的时间(以毫秒为单位)。 APIs GetRecords
SubscribeToShard
特性 | 共享吞吐量使用者,无需增强扇出 | 增强了粉丝群的消费者 |
---|---|---|
读取吞吐量 |
固定为 MB/sec 每个碎片总共有 2 个。如果有多个消费端正在从同一分片进行读取,则它们将全部共享此吞吐量。它们从分片中接收的吞吐量总和不会超出 2 MB/秒。 |
随着消费端注册进行扩展以使用增强型扇出功能。注册为使用增强型扇出功能的每个消费端均接收其自己的每个分片的读取吞吐量,最多 2MB/秒,独立于其他消费端。 |
消息传播延迟 |
平均约 200 毫秒(如果您有一个从流中读取的消费端)。如果您有五个消费端,则这个平均值高达约 1000 毫秒。 |
通常情况下,平均为 70 毫秒,无论您是拥有一个消费端,还是五个消费端。 |
成本 | 不适用 |
存在数据检索费用和消费端分片小时费用。有关更多信息,请参阅 Amazon Kinesis Data Streams 定价 |
记录传输模型 |
使用通过 HTTP 提取模型 GetRecords。 |
Kinesis Data Streams 使用通过 HTTP/ SubscribeToShard 2 将记录推送给你。 |