Appearance
位点提交策略怎么影响消费语义
Kafka 消费者真正难的地方，往往不是“会不会拉消息”，而是下面这件事：
你在什么时候提交位点，决定了失败后会重复消费、丢消息，还是牺牲吞吐换稳定。
很多线上积压、重复消费、消息漏处理问题，最后都能回到位点提交策略上。
先说结论
- 位点提交本质上是在声明“这批消息我处理到哪里了”
- 先提交再处理，可能丢消息；先处理再提交，可能重复消费
- Kafka 默认更容易提供至少一次语义，精确一次需要额外配套
- 位点策略必须和幂等消费、批量处理、再均衡一起设计
位点到底是什么
Kafka 的每个分区都是有序日志。
消费者读取时，会记录“我读到哪个 offset 了”。
注意这里有一个容易混淆的点：
- 已拉取到本地，不等于已处理成功
- 已处理成功，不等于位点已提交
位点提交，提交的是“下次从哪开始继续读”。
为什么提交时机会影响消费语义
假设一批消息被消费者拉到本地后，业务逻辑还没执行完成，进程突然挂了。
情况一: 先提交位点，再处理业务
位点已经往前推进了。
消费者重启后会从更后面的消息开始读，这批尚未处理成功的消息就可能丢失。
情况二: 先处理业务，再提交位点
如果业务已经执行成功，但提交位点前进程挂了，重启后还会再读一次。
这时会出现重复消费。
这就是 Kafka 消费语义的核心权衡：
- 早提交偏向可能丢
- 晚提交偏向可能重
自动提交为什么容易踩坑
Kafka 支持自动提交位点。
很多项目为了省事直接开着，但这在业务消费里往往不稳。
因为自动提交通常只按时间周期推进，不关心你的业务是否真正处理完成。
如果业务处理耗时、存在异步线程、或者批量写库失败，自动提交很容易让位点跑到业务前面。
适合自动提交的场景一般是：
- 处理逻辑极轻
- 容忍少量重复或丢失
- 更像日志消费、指标上报，而不是核心业务链路
手动提交的几种常见方式
1. 同步提交
业务处理完成后调用同步 commit。
优点是结果明确，失败可感知；缺点是提交路径阻塞，吞吐会受影响。
2. 异步提交
性能更好，但提交失败时要设计回调处理，否则很容易默默失败。
3. 批量提交
一批消息都处理成功后统一提交最后一个位点。
这是很多高吞吐消费者的常见做法。
但要注意：
- 批次越大，失败重试时重复消费的范围越大
- 批次越小，提交开销越高
再均衡为什么会放大问题
消费者组发生 rebalance 时，分区会被重新分配。
如果旧消费者在分区被撤销前没有把“已处理完成的位点”稳妥提交，新的消费者接手后就容易出现：
- 重复消费
- 漏消费判断困难
- 某些批次处理状态不清楚
所以在 rebalance 场景下，常见做法是：
- 在分区撤销回调里提交已处理完成的位点
- 确保本地缓冲、线程池和业务处理状态能与分区生命周期对齐
至少一次、至多一次、精确一次怎么对应
至多一次
先提交位点，再处理消息。
消息大概率不会重复，但有丢失风险。
至少一次
先处理业务，再提交位点。
消息可能重复，但只要业务幂等，就能保证最终结果正确。
精确一次
不是单靠位点提交就能实现的。
通常需要结合：
- 生产端幂等或事务
- 消费端幂等
- 结果写入与位点推进的一致性设计
对大多数业务来说，真正可落地的是：
- Kafka 至少一次
- 业务侧幂等保证结果“近似精确一次”
一套更现实的工程方案
如果是订单、支付、库存、优惠券这类核心业务，通常推荐：
- 手动提交位点
- 业务处理成功后再提交
- 消费逻辑幂等化
- 处理失败走重试或补偿
- rebalance 前主动刷位点
这样虽然可能重复，但一般不会漏。
常见误区
1. 以为提交位点就是确认消费成功
错。
位点只是“恢复起点”，不是业务事务提交证明。
2. 异步线程处理却主线程先提交位点
这在实际项目里非常常见，也非常危险。
主线程觉得“消息已经交给线程池了”，于是提前提交，结果异步执行失败就直接漏了。
3. 没有幂等却追求高吞吐批量提交
批量处理越大，重复消费影响面越大。
没有幂等保护时，很容易把问题放大。
排障时怎么定位位点策略问题
当你发现重复消费或疑似漏消费时，可以顺着这条线排查：
- 位点是自动提交还是手动提交
- 提交发生在业务处理前还是后
- 是否存在线程池异步消费
- rebalance 时是否处理了分区撤销回调
- 业务是否具备幂等保护
很多“Kafka 不可靠”的问题，最后本质上都是消费端位点推进时机设计得不对。
总结
位点提交策略不是一个配置细节，而是消费语义的核心开关。
它决定了系统在故障发生时更偏向“重复”还是“丢失”。
大多数核心业务系统的正确方向，不是追求绝对不重复，而是选择“至少一次 + 业务幂等 + 可回查”。