Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit 4fa1c44

Browse files
committedJan 17, 2019
docs: update image of kafka to fix doocs#28
- 修改 Kafka 图片小错误 - 调整图片展示位置
1 parent efcc3ef commit 4fa1c44

File tree

3 files changed

+3
-4
lines changed

3 files changed

+3
-4
lines changed
 

‎docs/high-concurrency/how-to-ensure-that-messages-are-not-repeatedly-consumed.md

+3-4
Original file line numberDiff line numberDiff line change
@@ -13,14 +13,13 @@ Kafka 实际上有个 offset 的概念,就是每个消息写进去,都有一
1313

1414
但是凡事总有意外,比如我们之前生产经常遇到的,就是你有时候重启系统,看你怎么重启了,如果碰到点着急的,直接 kill 进程了,再重启。这会导致 consumer 有些消息处理了,但是没来得及提交 offset,尴尬了。重启之后,少数消息会再次消费一次。
1515

16-
![mq-10](/images/mq-10.png)
17-
1816
举个栗子。
1917

20-
有这么个场景。数据 1/2/3 依次进入 kafka,kafka 会给这三条数据每条分配一个 offset,代表这条数据的序号,分配的 offset 依次是 152/153/154。消费者从 kafka 去消费的时候,也是按照这个顺序去消费。假如当消费者消费了 `offset=153` 的这条数据,刚准备去提交 offset 到 zookeeper,此时消费者进程被重启了。那么此时消费过的数据 1/2 的 offset 并没有提交,kafka 也就不知道你已经消费了 `offset=153` 这条数据。那么重启之后,消费者会找 kafka 说,嘿,哥儿们,你给我接着把上次我消费到的那个地方后面的数据继续给我传递过来。数据 1/2 再次被消费
18+
有这么个场景。数据 1/2/3 依次进入 kafka,kafka 会给这三条数据每条分配一个 offset,代表这条数据的序号,我们就假设分配的 offset 依次是 152/153/154。消费者从 kafka 去消费的时候,也是按照这个顺序去消费。假如当消费者消费了 `offset=153` 的这条数据,刚准备去提交 offset 到 zookeeper,此时消费者进程被重启了。那么此时消费过的数据 1/2 的 offset 并没有提交,kafka 也就不知道你已经消费了 `offset=153` 这条数据。那么重启之后,消费者会找 kafka 说,嘿,哥儿们,你给我接着把上次我消费到的那个地方后面的数据继续给我传递过来。由于之前的 offset 没有提交成功,那么数据 1/2 会再次传过来,如果此时消费者没有去重的话,那么就会导致重复消费
2119

22-
如果消费者干的事儿是拿一条数据就往数据库里写一条,会导致说,你可能就把数据 1/2 在数据库里插入了 2 次,那么数据就错啦。
20+
![mq-10](/images/mq-10.png)
2321

22+
如果消费者干的事儿是拿一条数据就往数据库里写一条,会导致说,你可能就把数据 1/2 在数据库里插入了 2 次,那么数据就错啦。
2423

2524
其实重复消费不可怕,可怕的是你没考虑到重复消费之后,**怎么保证幂等性**
2625

13.9 KB
Loading

‎images/mq-10.png

13.9 KB
Loading

0 commit comments

Comments
 (0)
Please sign in to comment.