如何确定AWS Kinesis流中分区键的总数？

Question

在生产者-消费者的 Web 应用程序中，为 Kinesis Stream 分片创建分区键应该遵循什么思路？假设我有一个具有 16 个分片的 Kinesis 流，那么我应该创建多少个分区键呢？这是否真的取决于分片数量？

- shivba

---

看一下这个问题，也许会有所帮助；http://stackoverflow.com/a/31377161/1622134 - az3

Answer 1

分区（或哈希）键：从1开始，最大值为340282366920938463463374607431768211455。假设为~34020 * 10^34，我将为方便起见省略10^34...

如果您有30个均匀分布的碎片，则每个碎片应涵盖1134 * 10^34个哈希键。覆盖范围应如下：

Shard-00：0-1134 Shard-01：1135-2268 Shard-03：2269-3402 Shard-04：3403-4536 ... Shard-28：30619-31752 Shard-29：31753-32886 Shard-30：32887-34020

如果您有3个消费者应用程序（监听这30个碎片），则每个应监听10个碎片（最佳平衡）。

这也解释了流上的合并和拆分操作。

• 要合并2个碎片，它们应覆盖相邻的哈希键。您不能合并Shard-03和Shard-29。
• 您可以拆分任何碎片。如果在Shard-00中间拆分碎片，则分配情况将如下所示：

Shard-31：0-567 Shard-32：568-1134 Shard-01：1135-2268 Shard-03：2269-3402 Shard-04：3403-4536 ... Shard-28：30619-31752 Shard-29：31753-32886 Shard-30：32887-34020

看，Shard-00将不再接受新数据。与Shard-00具有相同分区键范围的新记录将放置在Shard-31或Shard-32下。

发送数据到Kinesis（即生产者端）时，您不需要担心“数据会被分配到哪个分片中”。发送一个随机数（或uuid或当前时间戳，以毫秒为单位）是为了使数据在分片上有效地进行扩展和分发。除非您担心在单个分片中记录的顺序，否则最好选择一个随机数/不断变化的分区键来发出put_record请求。

在Java中，您可以使用“putRecordsRequestEntry.setPartitionKey(Long.toString(System.currentTimeMillis()))”或“putRecordRequest.setPartitionKey(Long.toString(System.currentTimeMillis()))”作为示例。

- az3

---

我们在时间戳方面遇到了问题。毫秒级别的时间戳作为分区键并没有按照预期运行。因此，我们将其更改为UUID。 - Osman Alper

请注意，为每个消息创建uuid可能会消耗时间（和熵）。 - az3

谢谢，对我很有用 @az3。我的 Kinesis 流有 32 个分片，运行得非常完美。 - Bilal Demir

Answer 2

这完全取决于使用情况。你需要确保所有相关数据进入一个单独的分片，这样如果需要为一个键聚合数据，就可以实现。

如果你没有这个要求，使用任何随机键都应该是可以的。

- bhanu tadepalli