Kafka 的消息异常情况~追日

本文探讨了Kafka在消息传递中可能出现的问题,包括消息丢失、重复消费、乱序、积压、延时队列、回溯和分区对吞吐量的影响。针对这些问题,文章提供了相应的解决方案,如调整acks配置、实现消费幂等性、管理和优化分区数量等。
摘要由CSDN通过智能技术生成

Kafka 的消息异常情况

1.消息丢失情况

消息发送端 Producer

(1) acks=0: 表示 Producer 不需要等待任何 broker 确认收到消息的回复, 就可以继续发送下一条消息. 性能最高, 但是最容易丢消息. 对性能要求很高但对数据丢失不敏感的情况可以用这种模式.

(2) acks=1: 至少要等待 Leader 已经成功将数据写入本地 log, 但是不需要等待所有 Follower是否成功写入. 就可以继续发送下一条消息. 这种情况下, 如果 Follower 没有成功备份数据同时 Leader挂掉, 则会导致消息丢失.

(3)acks=-1或all: Leader 需要等待所有备份 (min.insync.replicas 配置备份个数参数设置)都成功写入日志, 这种策略会保证只要有一个备份存活就不会丢失数据. 如果 min.insync.replicas配置的是1则也可能丢消息, 类似于 acks=1情况.

消息消费端 Consumer

如果消费这边配置的是自动提交, 万一消费到数据还没处理完, 就自动提交 offset 了, 但是此时 Consumer 直接宕机了, 未处理完的数据丢失, 下次也消费不到.

2.消息重复消费

消息发送端 Producer

发送消息如果配置了重试机制, 比如网络抖动时间过长导致发送端发送超时, 实际broker可能已经接收到消息, 但发送方会重新发送消息

消息消费端 Consumer

如果消费这边配置的是自动提交, 刚拉取了一批数据处理了一部分, 但还没来得及提交, 服务

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值