本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
开发具有专用吞吐量的增强型扇出消费者
在 Amazon Kinesis Data Streams 中，可以构建使用增强型扇出功能的消费端。此功能允许使用者从每个分片每秒吞吐量高达 2 MB 的数据流中接收记录。此为专用吞吐量，这意味着，使用增强型扇出功能的消费端不必与接收流中数据的其他消费端争夺。Kinesis Data Streams 将流中的数据记录推送到使用增强型扇出功能的消费端。因此，这些消费端无需轮询数据。
重要
您可以为每个流注册多达 20 个消费端，以便使用增强型扇出功能。
下图显示的是增强型扇出功能架构。如果您使用版本 2.0 或更高版本的 Amazon Kinesis 客户端库 (KCL) 来构建使用器，则会将使用KCL器设置为使用增强的扇出来接收来自流中所有分片的数据。如果您使用API来构建使用增强型扇出功能的使用者，则可以订阅单个分片。
此图显示以下内容：
-
一个具有两个分片的流。
-
使用增强型扇出功能接收流中数据的两个消费端：消费端 X 和消费端 Y。这两个消费端均已订阅流的所有分片和所有记录。如果您使用版本 2.0 或更高版本KCL来构建消费者，则KCL会自动为该使用者订阅流中的所有分片。另一方面，如果您使用API来构建消费者，则可以订阅单个分片。
-
表示消费端用于接收流中数据的增强型扇出功能管道的箭头。增强型扇出功能管道每分片提供高达 2 MB/秒 数据，独立于任何其他管道或消费端的总数量。
整个消费者共享和增强型扇出消费者之间的区别
下表将默认共享吞吐量使用者与增强型扇出使用者进行了比较。消息传播延迟定义为使用负载调度（如和）发送的有效负载通过消耗负载（如和）到达使用者应用程序所花费的时间APIs（如PutRecord和PutRecords），以毫秒为单位。APIs GetRecords SubscribeToShard
| 特性 | 共享吞吐量使用者，无需增强扇出 | 增强了粉丝群的消费者 |
|---|---|---|
| 读取吞吐量 |
固定为总计 2 MB/sec per shard. If there are multiple consumers reading from the same shard, they all share this throughput. The sum of the throughputs they receive from the shard doesn't exceed 2 MB/sec。 |
随着消费端注册进行扩展以使用增强型扇出功能。注册为使用增强型扇出功能的每个消费端均接收其自己的每个分片的读取吞吐量，最多 2MB/秒，独立于其他消费端。 |
| 消息传播延迟 |
平均约 200 毫秒（如果您有一个从流中读取的消费端）。如果您有五个消费端，则这个平均值高达约 1000 毫秒。 |
通常情况下，平均为 70 毫秒，无论您是拥有一个消费端，还是五个消费端。 |
| 费用 | 不适用 |
存在数据检索费用和消费端分片小时费用。有关更多信息，请参阅 Amazon Kinesis Data Streams 定价 |
| 记录传输模型 |
HTTP使用将模型拉过来 GetRecords。 |
Kinesis Data Streams 使用/ SubscribeToShard2 将记录推送给你HTTP。 |
