From f0149525481a3e70909159446945b6059cfb65a0 Mon Sep 17 00:00:00 2001
From: machitao <1035937382@qq.com>
Date: Sun, 17 Oct 2021 22:42:22 +0800
Subject: [PATCH] =?UTF-8?q?feat:=E8=A1=A5=E5=85=85kafka=E4=B8=8D=E9=87=8D?=
 =?UTF-8?q?=E5=A4=8D=E6=B6=88=E8=B4=B9=E7=9A=84=E8=A7=A3=E7=AD=94?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../message-queue/Kafka常见面试题总结.md    | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

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