kafka基础——消息不丢失
2021-01-03 本文已影响0人
chase_lwf
内容
- producer消息不丢失
- consumer消息不丢失
生产端消息不丢失
- 不要使用 producer.send(msg),而要使用 producer.send(msg, callback)。记住,一定要使用带有回调通知的 send 方法。callback可以处理消息发送之后的逻辑,不一定就是失败的逻辑。retries是预防那种瞬时错误的,比如网络抖动这种问题;
- 设置 retries 为一个较大的值。这里的 retries 同样是 Producer 的参数,当出现网络的瞬时抖动时,消息发送可能会失败,此时配置了 retries > 0 的 Producer 能够自动重试消息发送,避免消息丢失。
- 设置 acks = all (1,0,-1,all), -1等同于all。all:所有的isr 副本都得相应成功才是成功,0 表示不管响应成功与否都返回给客户端成功,1 表示leaser要写入成功,才告诉producer客户端成,默认值是1,是吞吐率和可用性的折中方案。
- 设置 min.insync.replicas > 1。这是 Broker 端参数,控制的是消息至少要被写入到多少个副本才算是“已提交”。 min.insync.replicas规定了isr的数量,例如 min.insync.replicas为2,代表着isr副本数量要求为2,即: acks=all时, 要求2个副本写入成功才得行
- 设置 unclean.leader.election.enable = false。这是 Broker 端的参数,它控制的是哪些 Broker 有资格竞选分区的 Leader。如果一个 Broker 落后原先的 Leader 太多,那么它一旦成为新的 Leader,必然会造成消息的丢失。故一般都要将该参数设置成 false,即不允许这种情况的发生。
- 设置 replication.factor >= 3。这也是 Broker 端的参数,规定了分区副本数。
- 确保 replication.factor > min.insync.replicas。如果两者相等,那么只要有一个副本挂机,整个分区就无法正常工作了。我们不仅要改善消息的持久性,防止数据丢失,还要在不降低可用性的基础上完成。
- 推荐设置成 replication.factor = min.insync.replicas + 1。确保消息消费完成再提交。
消费端消息不丢失
- enable.auto.commit:最好把它设置成 false,代表是不自动提交消费位移,采用手动提交位移的方式来消费数据。
引用: - 《Kafka核心技术与实战_胡夕》