消息重复的场景及解决方案
消息重复和丢失是
kafka
中很常见的问题,主要发生在以下三个阶段:
1.
生产者阶段
2. broke
阶段
3.
消费者阶段
1 生产者阶段重复场景
生产发送的消息没有收到正确的broke响应,导致生产者重试。
生产者发出一条消息,broke落盘以后因为网络等种种原因发送端得到一个发送失败的响应或者网络中断,然后生产者收到一个可恢复的Exception重试消息导致消息重复。
说明:
1. new KafkaProducer()后创建一个后台线程KafkaThread扫描RecordAccumulator中是否有消 息;
2. 调用KafkaProducer.send()发送消息,实际上只是把消息保存到RecordAccumulator中;
3. 后台线程KafkaThread扫描到RecordAccumulator中有消息后,将消息发送到kafka集群;
4. 如果发送成功,那么返回成功;
5. 如果发送失败,那么判断是否允许重试。如果不允许重试,那么返回失败的结果;如果允许重试,把消息再保存到RecordAccumulator中,等待后台线程KafkaThread扫描再次发送;
可恢复异常说明
![](https://i-blog.csdnimg.cn/blog_migrate/17aa8729cdfa89db9ab385666b5e2d1c.png)
记录顺序问题
如果设置 max.in.flight.requests.per.connection 大于1(默认5,单个连接上发送的未确认请求的最大数量,表示上一个发出的请求没有确认下一个请求又发出了)。大于1可能会改变记录的顺序,因为如果将两个batch发送到单个分区,第一个batch处理失败并重试,但是第二个batch处理成功,那么第二个batch处理中的记录可能先出现被消费。
设置 max.in.flight.requests.per.connection 为1,可能会影响吞吐量,可以解决单个生产者发送顺序问题。如果多个生产者,生产者1先发送一个请求,生产者2后发送请求,此时生产者1返回可恢复异常,重试一定次数成功了。虽然生产者1先发送消息,但生产者2发送的消息会被先消费。
生产者发送重复解决方案
1 启动kafka的幂等性
要启动kafka的幂等性,设置: enable.idempotence=true ,以及 ack=all 以及 retries > 1。
2 ack=0,不重试。
可能会丢消息,适用于吞吐量指标重要性高于数据丢失,例如:日志收集。
生产者和broke阶段消息丢失场景
1 ack=0,不重试
生产者发送消息完,不管结果了,如果发送失败也就丢失了。
2 ack=1
,leader crash
生产者发送消息完,只等待
Leader
写入成功就返回了,
Leader
分区丢失了,此时
Follower
没来及 同步,消息丢失
3
unclean.leader.election.enable
配置
true
允许选举
ISR
以外的副本作为
leader,
会导致数据丢失,默认为
false
。生产者发送异步消息,只等待Lead写入成功就返回,
Leader
分区丢失,此时
ISR
中没有
Follower
,
Leader
从
OSR
中选举,因为
OSR
中本来落后于Leader
造成消息丢失。
解决生产者和
broke
阶段消息丢失
1
禁用
unclean
选举,
ack=all
ack=all /
-
1,tries > 1,unclean.leader.election.enable : false
生产者发完消息,等待
Follower
同步完再返回,如果异常则重试。副本的数量可能影响吞吐量,不超过5
个,一般三个。
不允许
unclean Leader
选举。
2
配置:
min.insync.replicas > 1
当生产者将
acks
设置为
all
(
或
-
1
)
时,
min.insync.replicas>1
。指定确认消息写成功需要的最小副本数量。达不到这个最小值,生产者将引发一个异常(
要么是
NotEnoughReplicas
,要么是NotEnoughReplicasAfterAppend)。
当一起使用时,
min.insync.replicas
和
ack
允许执行更大的持久性保证。一个典型的场景是创建一个复制因子为3
的主题,设置
min.insync
复制到
2
个,用
all
配置发送。将确保如果大多数副本没有收到写操作,则生产者将引发异常。
3.失败的
offset
单独记录
生产者发送消息,会自动重试,遇到不可恢复异常会抛出,这时可以捕获异常记录到数据库或缓存,进行单独处理。
消费者数据重复场景及解决方案
1 根本原因
数据消费完没有及时提交
offset
到
broker。
2
场景
消息消费端在消费过程中挂掉没有及时提交
offset
到
broke
,另一个消费端启动拿之前记录的
offset开始消费,由于offset
的滞后性可能会导致新启动的客户端有少量重复消费。
解决方案
1 取消自动提交
每次消费完或者程序退出时手动提交。这可能也没法保证一条重复。
2
下游做幂等
一般是让下游做幂等或者尽量每消费一条消息都记录
offset
,对于少数严格的场景可能需要把offset或唯一
ID
(例如订单
ID
)和下游状态更新放在同一个数据库里面做事务来保证精确的一次更新或者在下游数据表里面同时记录消费offset
,然后更新下游数据的时候用消费位移做乐观锁拒绝旧位移的数据更新