我不会起名字322 · 后端 / 算法 / 数据库
📘 技术栈 ｜ 🧩 力扣 Hot100 ｜ 🐹 Go 项目 ｜ 🟥 Redis ｜ 🐬 MySQL
文章目录
- Kafka 顺序消息为什么乱了：分区数变化与重试的 3 类原因
-
- 一、先说清楚 Kafka 的顺序保证边界
- 二、原因 1：分区数变了
- 三、原因 2：生产端重试导致的乱序
- 四、原因 3：消费端并发导致的乱序
- 五、还有一个坑：异步落库
- 六、带走物
Kafka 顺序消息为什么乱了：分区数变化与重试的 3 类原因
一、先说清楚 Kafka 的顺序保证边界
一句话：Kafka 只保证分区内有序，不保证 topic 全局有序。
这不是缺陷，是设计取舍——全局有序意味着只能有一个分区、一个消费者，吞吐直接归零。
所以"顺序乱了"这件事，第一步要确认的是：你依赖的顺序，是不是跨分区的？
# 看 topic 有几个分区
kafka-topics.sh –bootstrap-server localhost:9092 –describe –topic order-event
- 消息按 order_id 分区，你要求"同一个订单的事件有序" → Kafka 能满足，只要 key 用对；
- 你要求"所有订单的事件全局按时间有序" → Kafka 不满足，这是需求设计错了。
如果是后者，解法不是改 Kafka，而是在消费端做业务侧排序（比如按事件时间戳做窗口排序），或者干脆换成单分区 topic（牺牲吞吐）。
二、原因 1：分区数变了
这是最隐蔽的一类。
Kafka 的默认分区器是：hash(key) % partitionCount。注意分母是分区数。
分区数 = 3 时： order_id=100 → hash % 3 = 1 → 分区 1
分区数 = 4 时： order_id=100 → hash % 4 = 0 → 分区 0
同一个 key 在扩分区前后会落到不同的分区。 这就意味着：
结论：扩容分区会短暂破坏按 key 的顺序性。 如果你的业务严格依赖顺序，扩分区要在低峰期 + 消费无积压时做，并且接受短暂的顺序抖动。
另外还有一类更简单的：
// 错误：没指定 Key，走轮询分区
producer.Input() <- &sarama.ProducerMessage{
Topic: "order-event",
Value: sarama.StringEncoder(data),
// 没有 Key → 轮询，同一个订单的消息散到不同分区
}
// 正确：用业务主键做 Key
producer.Input() <- &sarama.ProducerMessage{
Topic: "order-event",
Key: sarama.StringEncoder(orderID), // 同一个订单永远进同一个分区
Value: sarama.StringEncoder(data),
}
"顺序乱了"有相当一部分是这个原因——压根没设 Key，消息从一开始就是散的。
三、原因 2：生产端重试导致的乱序
这是第二大类，而且和"可靠性配置"直接冲突。
场景：生产者发了两条消息 A、B（同一个分区），A 发送失败触发重试，B 发送成功。结果 B 先落盘，A 后落盘，顺序反了。
它和这个参数有关：
max.in.flight.requests.per.connection=5 # 默认 5
这个参数允许"最多 5 个请求同时在途、不用等前一个的确认"。在途请求多了，重试就可能插队。
旧版本的解法是把它设成 1（串行发送），代价是吞吐大幅下降：
max.in.flight.requests.per.connection=1 # 牺牲吞吐换顺序
更好的解法是开启幂等生产者（Kafka 0.11+）：
enable.idempotence=true
max.in.flight.requests.per.connection=5 # 幂等模式下最多 5，且不会乱序
原理：幂等生产者给每条消息带上序列号（每个分区一个递增 seq），broker 侧按序列号重新排序并去重。所以即使 A 重试后晚到，broker 也会把它放回正确位置，同时把重复的那条丢掉。
这是唯一一个"既不牺牲吞吐、又能保证顺序 + 不重复"的方案。 顺序敏感的场景应该默认开启。
config := sarama.NewConfig()
config.Producer.Idempotent = true
config.Producer.RequiredAcks = sarama.WaitForAll
config.Producer.Retry.Max = 3
注意：开启幂等后，acks 会被强制成 all，retries 会被强制成大于 0——这是 Kafka 的要求，不是 bug。
四、原因 3：消费端并发导致的乱序
这一类和 Kafka 无关，纯粹是消费者代码的问题：分区内是严格有序的，但你把它并发处理了。
// 错误：把同一个分区的消息丢进 goroutine 池
for msg := range claim.Messages() {
go handle(msg) // 并发 → 处理完成顺序不确定
}
即使 Kafka 保证了分区内顺序，你这么一并发，顺序就没了。
正确的做法是"分区内串行、分区间并行"：
func (h *handler) ConsumeClaim(sess sarama.ConsumerGroupSession, claim sarama.ConsumerGroupClaim) error {
// 这个方法对每个分区各跑一个 goroutine：分区间是并行的
for msg := range claim.Messages() {
// 而这里对单个分区是串行的：顺序得到保证
if err := handle(msg); err != nil {
return err
}
sess.MarkMessage(msg, "")
}
return nil
}
ConsumeClaim 的语义就是"每个分区一个 goroutine"，所以默认写法天然就是"分区内串行 + 分区间并行"。你要做的是别在里面再开 goroutine。
如果单分区处理太慢，正确的扩展方式是：
单分区慢 → 加分区数（让更多分区并行）→ 加消费者实例
而 不是 → 在分区内开 goroutine
五、还有一个坑：异步落库
最后一类特别隐蔽：消费端按顺序处理了，但下游写入乱了。
// 顺序处理，但异步写库
for msg := range claim.Messages() {
go db.Save(parse(msg)) // 写库并发 → 到达顺序不定
}
如果业务依赖"后一条覆盖前一条"（比如状态机 创建 → 支付 → 完成），并发写会让旧状态覆盖新状态。
解法要么串行写，要么在写入时带上版本号/时间戳做乐观锁：
UPDATE order SET status = ?, version = version + 1
WHERE id = ? AND version < ?
六、带走物
排查顺序乱了，按这四步走：
一句话结论：Kafka 的顺序保证是"分区内 + 幂等生产者开启"这两个前提同时成立才有效的；而消费端要做的恰恰是什么都别做——不要自己再并发。
