Kafka只对 “已提交” 的消息(committed message)做有限度的持久化保证;
概念
已提交消息
: 当Kafka的若干个 Broker 成功的接收到一跳消息并写入到日志系统后,就会通知生产者程序这条消息已提交;有限度的持久化保证
:如果你的消息保存在 N 个 Broker 节点上,那么持久化的前提就是这 N 个Broker至少有一个节点存活;
Kafka 是能做到不丢失消息的,只不过这些消息必须是已提交的消息,而且还要满足一定的条件。当然,说明这件事并不是要为 Kafka 推卸责任,而是为了在出现该类问题时我们能够明确责任边界。
消息丢失的可能原因
- Producer 发送API调用错误
Producer 应用向 Kafka发送消息,最后发现Kafka没有保存;
目前 Kafka Producer 是异步发送消息的,也就是说如果你调用的是 `producer.send(msg)` 这个 API,
那么它通常会立即返回,但此时你不能认为消息发送已成功完成。
该API调用如果出现丢失(网络抖动,消息太大等不合格消息体),生产者是无法感知的;
解决方案:Producer 永远使用带有回调通知的发送API:producer.send(msg, callback),
一旦出现失败,生产者可提供补救方案。
- Broker端宕机
- Consumer端丢失数据
`位移`:表示这个Consumer 当前消费到的 Topic分区的位置;
在消费消息的时候,需要先完成对消息的处理;再更新kafka中当前Consumer关于该Topic分区的位移值;
如此带来新的问题:重复读;
- 多线程场景下,消息丢失
Consumer端采用多线程的方式,异步处理消息;如果某个线程运行失败;在开启自动提交位移的情况下会导致消息丢失;
解决方案:
在该场景下,Consumer端不能启用自动位移提交,而应该手动提交位移;
而需要注意的是多线程提交位移实现的正确性;
最佳实践
- 不要使用 producer.send(msg),而要使用 producer.send(msg, callback)。记住,一定要使用带有回调通知的 send 方法。
- 设置
acks = all
。acks 是 Producer 的一个参数,代表了你对“已提交”消息的定义。如果设置成 all,则表明所有副本 Broker 都要接收到消息,该消息才算是“已提交”。这是最高等级的“已提交”定义。 - 设置
retries
为一个较大的值。这里的 retries 同样是 Producer 的参数,对应前面提到的 Producer 自动重试。当出现网络的瞬时抖动时,消息发送可能会失败,此时配置了 retries > 0 的 Producer 能够自动重试消息发送,避免消息丢失。 - 设置
unclean.leader.election.enable = false
。这是 Broker 端的参数,它控制的是哪些 Broker 有资格竞选分区的 Leader。如果一个 Broker 落后原先的 Leader 太多,那么它一旦成为新的 Leader,必然会造成消息的丢失。故一般都要将该参数设置成 false,即不允许这种情况的发生。 - 设置
replication.factor >= 3
。这也是 Broker 端的参数。其实这里想表述的是,最好将消息多保存几份,毕竟目前防止消息丢失的主要机制就是冗余。 - 设置
min.insync.replicas > 1
。这依然是 Broker 端参数,控制的是消息至少要被写入到多少个副本才算是“已提交”。设置成大于 1 可以提升消息持久性。在实际环境中千万不要使用默认值 1。 - 确保
replication.factor > min.insync.replicas
。如果两者相等,那么只要有一个副本挂机,整个分区就无法正常工作了。我们不仅要改善消息的持久性,防止数据丢失,还要在不降低可用性的基础上完成。推荐设置成replication.factor = min.insync.replicas + 1
。 - 确保消息消费完成再提交。Consumer 端有个参数
enable.auto.commit
,最好把它设置成false
,并采用手动提交位移的方式。就像前面说的,这对于单 Consumer 多线程处理的场景而言是至关重要的。