Apache Kafka压缩键（MD5哈希）碰撞是否安全？不同键会被覆盖吗？

你的推测方向基本正确，但存在细节偏差，具体分析如下：

1. SkimpyOffsetMap的核心作用 #

SkimpyOffsetMap是Kafka日志压缩机制中，用来在内存中追踪每个键对应最新消息偏移量的结构。压缩时，Kafka会依据这个映射保留每个键的最新版本消息，删除旧版本。

2. 哈希碰撞时的代码逻辑 #

你贴出的这段代码逻辑很明确：当新键计算出的MD5哈希（hash2）与映射中已存在的哈希（hash1）相等时，会直接覆盖该位置存储的偏移量为当前消息的偏移量，且不增加映射的条目数。这里的场景就是两个不同的键产生了MD5哈希碰撞。

3. 对压缩行为的实际影响 #

此时Kafka会错误地将这两个不同的键视为同一个键：

• 后写入的消息的偏移量会覆盖前一个键的偏移量记录；
• 压缩阶段，Kafka只会保留偏移量与映射中记录一致的消息，其他所有旧版本（包括另一个键的最新消息）都会被标记为可删除。

最终结果不是“仅保留偏移量最新的那个键”，而是两个碰撞的键中，只有最后写入的那条消息会被保留，另一个键的所有消息都会被压缩删除——本质是哈希碰撞导致键的追踪出现混淆，而非刻意保留最新键。

补充说明 #

Kafka使用的MD5是128位哈希算法，实际运行中哈希碰撞的概率极低，属于极端边缘场景，但一旦发生就会引发上述异常压缩行为。

内容的提问来源于stack exchange，提问作者raphaelauv