Kafka与Event Hubs中事件排序与日志压缩的冲突处理问询

Apache Kafka 和 Azure Event Hubs 都支持日志压缩功能，但二者有个共同限制：分区键就是压缩键——也就是说，只要是分区键相同的旧事件，都会被压缩清理掉。另外，事件的顺序只有在同一个分区内才能得到严格保证，所以有排序依赖的事件必须被路由到同一个分区。

那如果遇到「有排序依赖的不同事件不能被一起压缩」的场景，该怎么处理？

举个座位预订的实际例子：

1. SeatReserved (用户: A, 座位: 1)
2. SeatCancelled (用户: A, 座位: 1)
3. SeatReserved (用户: A, 座位: 2)

这里事件的顺序绝对不能乱，所以三个事件必须在同一个分区里，用「用户ID」作为分区键是最合理的选择。但问题来了：如果用用户ID当压缩键，日志压缩会把旧的事件（1和2）都删掉，只保留最新的事件3——可实际上我们需要保留事件2和3，因为它们分别记录了座位1的取消和座位2的预订状态，都是有效信息。理想的压缩键应该是「事件类型+用户ID+座位号」，但这样设置的话，三个事件的分区键会不一样，很大概率被分到不同分区，直接丢失了顺序保证。

针对这个矛盾，有几个可行的解决思路：

1. 自定义分区路由 + 复合压缩键 #

既然分区键和压缩键绑定，我们可以把「分区路由规则」和「压缩键」解耦：

• 发送消息时，根据用户ID固定路由到指定分区（比如自定义分区器，或者提前计算用户ID对应的分区号并手动指定），确保同一用户的所有事件都进入同一个分区，保证顺序；
• 把「用户ID+座位号+事件类型」作为消息的键（也就是压缩键），这样日志压缩只会清理掉同一用户、同一座位、同一事件类型的旧事件，不会误删其他相关事件。

这种方式既满足了事件排序的要求，又实现了精准的压缩规则，是最常用的解决方案。

2. 禁用日志压缩，改用时间/大小驱动的清理策略 #

如果业务对存储成本的敏感度不高，或者事件保留周期明确，可以直接关闭主题的日志压缩功能，转而使用基于时间或存储大小的自动清理策略。这样所有事件都会被保留到过期时间，自然不会出现误删有排序依赖事件的问题。

3. 调整事件建模，用状态快照替代事件链 #

换一种事件设计思路：把离散的操作事件（预订/取消）合并成统一的状态更新事件，比如发送 SeatStatusUpdated 事件，包含用户ID、座位号和当前状态（已预订/已取消）。

• 用「用户ID」作为分区路由依据，保证同一用户的所有状态更新顺序；
• 用「用户ID+座位号」作为消息键（压缩键），日志压缩会自动保留每个座位的最新状态，同时不会影响其他座位的状态记录。

这种方式简化了事件结构，也天然适配了日志压缩的特性，但需要业务侧能接受用状态快照替代完整的事件链。

内容的提问来源于Stack Exchange，提问作者Andreas Ågren