diff --git "a/docs/system-design/distributed-system/message-queue/Kafka\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230\346\200\273\347\273\223.md" "b/docs/system-design/distributed-system/message-queue/Kafka\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230\346\200\273\347\273\223.md"
index 8165d7a781f013c6cc8f8d12fb99e6d2467c3a82..f06dd9b3d789a2f4de953b4b4296ad90f8c8b498 100644
--- "a/docs/system-design/distributed-system/message-queue/Kafka\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230\346\200\273\347\273\223.md"
+++ "b/docs/system-design/distributed-system/message-queue/Kafka\345\270\270\350\247\201\351\235\242\350\257\225\351\242\230\346\200\273\347\273\223.md"
@@ -207,8 +207,18 @@ acks 的默认值即为1,代表我们的消息被leader副本接收之后就
### Kafka 如何保证消息不重复消费
-代办...
-
+1. **kafka出现消息重复消费的原因**
+ * 服务端侧 已经消费的数据没有成功提交 offset(根本原因)
+ * kafka 侧 由于服务端处理业务时间长或者网络链接等等原因让 kafka 认为服务假死,触发了分区 rebalance
+2. **解决方案**
+ * 最有效:消费消息服务做幂等校验,比如redis的set、mysql的主键等天然的幂等功能
+ * 将 **enable.auto.commit** 参数设置为 false,关闭自动提交,开发者在代码中手动提交 offset。那么这里会有个
+ 问题:
+ **什么时候提交offset合适?**
+ * 处理完消息再提交:依旧有消息重复消费的风险,和自动提交一样
+ * 拉取到消息即提交:会有消息丢失的风险。允许消息延时的场景,一般会采用这种方式。然后通过定时任
+ 务在业务不繁忙的时候做数据兜底,一般是基建较好的公司会通过大数据部门在晚上兜底
+
### Reference
- Kafka 官方文档: https://kafka.apache.org/documentation/