消息丢失问题在所有消息中间价都是一个大问题,那么kafka是如何保证消息不丢失的呢?
目录
责任边界
可以概括为:Kafka 只对“已提交”的消息(committed message)做有限度的持久化保证。
什么是已提交的消息?当 Kafka 的若干个 Broker 成功地接收到一条消息并写入到日志文件后,它们会告诉生产者程序这条消息已成功提交。此时,这条消息在 Kafka 看来就正式变为“已提交”消息了。为什么是若干个 Broker 呢?着取决于Broker端的配置。
有限度就是说 Kafka 不可能保证在任何情况下都做到不丢失消息。比如机房断电、机房火灾等极端情况。
消息丢失案例
生产者丢失
Producer 程序丢失消息,这应该算是被抱怨最多的数据丢失场景了。比如这个场景:你写了一个 Producer 应用向 Kafka 发送消息,最后发现 Kafka 没有保存,然后客户端又没有相关日志报错,让你无从下手。
我们来分析下可能的原因,Kafka Producer 是异步发送消息的,当你调用producer.send(msg) ,它会立即返回,但此时你不能认为消息发送已成功完成。这种发送方式有个有趣的名字,叫“fire and forget”,简单翻译就是“发后即忘”。用该方式当发生网络抖动,消息格式错误等问题时不能及时发现,那我们不能甩锅给kafka。事实上我们应该使用带回调的发送方式producer.send(msg, callback),通过回调我们才能真正确定是否发送成功,或是出了什么问题。
消费者丢失
Consumer 程序有个“位移”的概念,表示的是这个 Consumer 当前消费到的 Topic 分区的位置。
这里的“位移”类似于我们看书时使用的书签,它会标记我们当前阅读了多少页,下次翻书的时候我们能直接跳到书签页继续阅读。假如你读到第50页,但是却不小心将书签放在60页,那就丢了中间10页内容。同理,Kafka 中 Consumer 端的消息丢失也如此。要处理这种消息丢失,办法很简单:维持先消费消息(阅读),再更新位移(书签)的顺序即可。这样就能最大限度地保证消息不丢失。
最佳实践
根据以上内容,可以得出一下最佳实践:
- 不要使用 producer.send(msg),而要使用 producer.send(msg, callback)。记住,一定要使用带有回调通知的 send 方法。
- acks = all。acks 是 Producer 的一个参数,代表了你对“已提交”消息的定义。如果设置成 all,则表明所有ISR副本 Broker 都要接收到消息,该消息才算是“已提交”。
- retries 为一个较大的值。这里的 retries 同样是 Producer 的参数。当出现网络的瞬时抖动时,如果配置了 retries > 0 的 Producer 能够自动重试消息发送。
- replication.factor >= 3。 Broker 端的参数,将消息多保存几份,毕竟目前防止消息丢失的主要机制就是冗余。
- min.insync.replicas(ISR) > 1。 Broker 端参数,控制的是消息至少要被写入到多少个副本才算是“已提交”。设置成大于 1 可以提升消息持久性。在实际环境中千万不要使用默认值 1。
- 确保 replication.factor > min.insync.replicas。如果两者相等,那么只要有一个副本挂机,整个分区就无法正常工作了。推荐设置成 replication.factor = min.insync.replicas + 1。