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 1/2] =?UTF-8?q?feat:=E8=A1=A5=E5=85=85kafka=E4=B8=8D?= =?UTF-8?q?=E9=87=8D=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 --- ...257\225\351\242\230\346\200\273\347\273\223.md" | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) 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 8165d7a781f..f06dd9b3d78 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/ From 83519ffcb46ebaa709334c3a90c5570649a69470 Mon Sep 17 00:00:00 2001 From: guide Date: Mon, 18 Oct 2021 20:50:12 +0800 Subject: [PATCH 2/2] =?UTF-8?q?Update=20Kafka=E5=B8=B8=E8=A7=81=E9=9D=A2?= =?UTF-8?q?=E8=AF=95=E9=A2=98=E6=80=BB=E7=BB=93.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...25\351\242\230\346\200\273\347\273\223.md" | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) 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 f06dd9b3d78..4077bd95898 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,18 +207,18 @@ acks 的默认值即为1，代表我们的消息被leader副本接收之后就 ### Kafka 如何保证消息不重复消费 -1. **kafka出现消息重复消费的原因** - * 服务端侧 已经消费的数据没有成功提交 offset（根本原因） - * kafka 侧 由于服务端处理业务时间长或者网络链接等等原因让 kafka 认为服务假死，触发了分区 rebalance -2. **解决方案** - * 最有效：消费消息服务做幂等校验，比如redis的set、mysql的主键等天然的幂等功能 - * 将 **enable.auto.commit** 参数设置为 false，关闭自动提交，开发者在代码中手动提交 offset。那么这里会有个
- 问题： - **什么时候提交offset合适？** - * 处理完消息再提交：依旧有消息重复消费的风险，和自动提交一样 - * 拉取到消息即提交：会有消息丢失的风险。允许消息延时的场景，一般会采用这种方式。然后通过定时任
- 务在业务不繁忙的时候做数据兜底，一般是基建较好的公司会通过大数据部门在晚上兜底 - +**kafka出现消息重复消费的原因：** + +- 服务端侧已经消费的数据没有成功提交 offset（根本原因）。 +- Kafka 侧 由于服务端处理业务时间长或者网络链接等等原因让 Kafka 认为服务假死，触发了分区 rebalance。 + +**解决方案：** + +- 消费消息服务做幂等校验，比如 Redis 的set、MySQL 的主键等天然的幂等功能。这种方法最有效。 +- 将 **`enable.auto.commit`** 参数设置为 false，关闭自动提交，开发者在代码中手动提交 offset。那么这里会有个问题：**什么时候提交offset合适？** + * 处理完消息再提交：依旧有消息重复消费的风险，和自动提交一样 + * 拉取到消息即提交：会有消息丢失的风险。允许消息延时的场景，一般会采用这种方式。然后，通过定时任务在业务不繁忙（比如凌晨）的时候做数据兜底。 + ### Reference - Kafka 官方文档： https://kafka.apache.org/documentation/