kafka消息防丢失的策略

450 阅读2分钟
1、不要使⽤ producer.send(msg),⽽要使⽤ producer.send(msg, callback)。记住,⼀定要使⽤带有回调通知的 send ⽅法。
2、设置 acks = all。acks 是 Producer 的⼀个参数,代表了你对“已提交”消息的定义。如果设置成 all,则表明所有副本 Broker 都要接收到消息,该消息才算是“已提交”。这是最⾼等级的“已提交”定义。
3、设置 retries 为⼀个较⼤的值。这⾥的 retries 同样是 Producer 的参数,对应前⾯提到的Producer ⾃动重试。当出现⽹络的瞬时抖动时,消息发送可能会失败,此时配置了 retries > 0 的Producer 能够⾃动重试消息发送,避免消息丢失。
4、设置 unclean.leader.election.enable = false。这是 Broker 端的参数,它控制的是哪些Broker 有资格竞选分区的 Leader。如果⼀个 Broker 落后原先的 Leader 太多,那么它⼀旦成为新的 Leader,必然会造成消息的丢失。故⼀般都要将该参数设置成 false,即不允许这种情况的发⽣。
5、设置 replication.factor >= 3。这也是 Broker 端的参数。其实这⾥想表述的是,最好将消息多保存⼏份,毕竟⽬前防⽌消息丢失的主要机制就是冗余。
6、设置 min.insync.replicas > 1。这依然是 Broker 端参数,控制的是消息⾄少要被写⼊到多少个副本才算是“已提交”。设置成⼤于 1 可以提升消息持久性。在实际环境中千万不要使⽤默认值1。
7、确保 replication.factor > min.insync.replicas。如果两者相等,那么只要有⼀个副本挂机,整个分区就⽆法正常⼯作了。我们不仅要改善消息的持久性,防⽌数据丢失,还要在不降低可⽤性的基础上完成。推荐设置成 replication.factor = min.insync.replicas + 1。
8、确保消息消费完成再提交。Consumer 端有个参数 enable.auto.commit,最好把它设置成false,并采⽤⼿动提交位移的⽅式。就像前⾯说的,这对于单 Consumer 多线程处理的场景⽽⾔