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

Question

在生产者 - 消费者Web应用程序中，为kinesis流碎片创建分区键的思考过程应该是什么。 假设，我有一个带有16个分片的kinesis流，我应该创建多少个分区键？它真的取决于碎片的数量吗？

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个分片（最佳平衡）。

这也解释了Stream上的Merge和Split操作。

• 要合并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将不再接受新数据。放在具有相同分区键范围的Kinesis流中的新记录（如Shard-00）将放置在Shard-31或Shard-32下。

在向Kinesis（即生产者方）发送数据时，您不必担心“数据转到哪个分片”。发送随机数（或以毫安为单位的uuid或当前时间戳）最适合在分片上有效地扩展和分发数据。除非您担心单个分片中的记录顺序，否则最好为put_record请求选择随机数/不断更改的分区键。

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

Answer 2

完全取决于用例。 您需要确保所有相关数据都转到一个分片，以便您可以根据需要聚合密钥的数据。

如果您没有使用任何随机密钥的要求应该没问题。