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