默认的Kafka分区器创建哈希键冲突

Question

我有一个包含 10 个分区的主题，并且生成了具有A,B,C,D,E,F,G,H,I9 个不同键的事件。

我观察到消息这样做：

Partition 0- (Message1, Key E), (Message2, Key I)
Partition 1- (Message3, Key F) 
. 
. 
Partition7-(Message4, Key A), (Message5, Key A)
Partition8- Empty 
Partition9- Empty

同一分区中有 2 条具有不同键的消息，并且也有空分区。

Kafka 的默认分区器是否会产生冲突？

我从一个流中进行生产，该流与两个默认的其余生产者保持平衡。

这就是我所期待的：

 Partition 0- (Message1, Key E)
 Partition 1- (Message3, Key F) 
 . 
 . 
 Partition7-(Message4, Key A), (Message5, Key A)
 Partition8-(Message2, Key I) 
 Partition9- Empty

Answer 1

Kafka的DefaultPartitioner在生产者客户端使用杂音哈希算法为每条消息分配一个分区。不保证对于 10 个分区和个位数的键，它们会均匀分布。每个消息的分区计算是相互独立的，并且碰撞概率是一个数学兴趣。

编辑：

murmur 哈希算法不太可能导致冲突。Kafka 主题中的分区是固定的 - 与 Java HashMap 实现中的存储桶大小不同，它不能增长。因此，分区算法使用计算分区数模的公式。确切的公式是Utils.toPositive(Utils.murmur2(keyBytes)) % numPartitions;

现在您可以看到，如果两个不同的键hash mod number of partitions产生相同的值，则确实可以产生相同的分区号。

对于大量随机密钥集，密钥将均匀分布在所有分区上。

如果你想要排序，那么你必须使用分区键..在这种情况下，你对冲突和空分区的担忧几乎没有实际后果（好吧，对于一大组随机键，它们会没问题）。如果您假设 Kafka 会集中确保先填充空分区，然后再将键路由到已填充的分区，那么事情并非如此