kafka消息丢失解决方案

，下面我们就来看看如何解决才能最大限度的保证消息不丢失。

 

 

Producer 端解决方案

 

 

在剖析 Producer 端丢失场景的时候， 我们得出其是通过「异步」方式进行发送的，所以如果此时是使用「发后即焚」的方式发送，即调用 Producer.send(msg) 会立即返回，由于没有回调，可能因网络原因导致 Broker 并没有收到消息，此时就丢失了。

 

 

因此我们可以从以下几方面进行解决 Producer 端消息丢失问题：

 

 

4.1.1 更换调用方式：

 

 

弃用调用发后即焚的方式，使用带回调通知函数的方法进行发送消息，即 Producer.send(msg, callback), 这样一旦发现发送失败， 就可以做针对性处理。

 

 

　　

 

 

（1）网络抖动导致消息丢失，Producer 端可以进行重试。

 

 

（2）消息大小不合格，可以进行适当调整，符合 Broker 承受范围再发送。

 

 

通过以上方式可以保证最大限度消息可以发送成功。

 

 

4.1.2 ACK 确认机制：

 

 

该参数代表了对"已提交"消息的定义。

 

 

需要将 request.required.acks 设置为 -1/ all，-1/all 表示有多少个副本 Broker 全部收到消息，才认为是消息提交成功的标识。

 

 

针对 acks = -1/ all , 这里有两种非常典型的情况：

 

 

（1）数据发送到 Leader Partition， 且所有的 ISR 成员全部同步完数据， 此时，Leader Partition 异常 Crash 掉，那么会选举新的 Leader Partition，数据不会丢失， 如下图所示：

 

 

（2）数据发送到 Leader Partition，部分 ISR 成员同步完成，此时 Leader Partition 异常 Crash， 剩下的 Follower Partition 都可能被选举成新的 Leader Partition，会给 Producer 端发送失败标识， 后续会重新发送数据，数据可能会重复， 如下图所示：

 

 

因此通过上面分析，我们还需要通过其他参数配置来进行保证：

 

 

replication.factor >= 2

 

 

min.insync.replicas > 1

 

 

这是 Broker 端的配置，下面会详细介绍。

 

 

4.1.3 重试次数 retries：

 

 

该参数表示 Producer 端发送消息的重试次数。

 

 

需要将 retries 设置为大于0的数， 在 Kafka 2.4 版本中默认设置为Integer.MAX_VALUE。另外如果需要保证发送消息的顺序性，配置如下：

 

 

这样 Producer 端就会一直进行重试直到 Broker 端返回 ACK 标识，同时只有一个连接向 Broker 发送数据保证了消息的顺序性。

 

 

4.1.4 重试时间 retry.backoff.ms：
该参数表示消息发送超时后两次重试之间的间隔时间，避免无效的频繁重试，默认值为100ms, 推荐设置为300ms。

 

 

Broker 端解决方案

 

 

在剖析 Broker 端丢失场景的时候， 我们得出其是通过「异步批量刷盘」的策略，先将数据存储到 「PageCache」，再进行异步刷盘， 由于没有提供 「同步刷盘」策略， 因此 Kafka 是通过「多分区多副本」的方式来最大限度的保证数据不丢失。

 

 

我们可以通过以下参数配合来保证：

 

 

4.2.1 unclean.leader.election.enable：

 

 

该参数表示有哪些 Follower 可以有资格被选举为 Leader , 如果一个 Follower 的数据落后 Leader 太多，那么一旦它被选举为新的 Leader， 数据就会丢失，因此我们要将其设置为false，防止此类情况发生。

 

 

4.2.2 replication.factor：
该参数表示分区副本的个数。建议设置 replication.factor >=3, 这样如果 Leader 副本异常 Crash 掉，Follower 副本会被选举为新的 Leader 副本继续提供服务。

 

 

4.2.3 min.insync.replicas：
该参数表示消息至少要被写入成功到 ISR 多少个副本才算"已提交"，建议设置min.insync.replicas > 1, 这样才可以提升消息持久性，保证数据不丢失。

 

 

另外我们还需要确保一下 replication.factor > min.insync.replicas, 如果相等，只要有一个副本异常 Crash 掉，整个分区就无法正常工作了，因此推荐设置成： replication.factor = min.insync.replicas +1, 最大限度保证系统可用性。

 

 

Consumer 端解决方案

 

 

在剖析 Consumer 端丢失场景的时候，我们得出其拉取完消息后是需要提交 Offset 位移信息的，因此为了不丢数据，正确的做法是：拉取数据、业务逻辑处理、提交消费 Offset 位移信息。

 

 

我们还需要设置参数 enable.auto.commit = false, 采用手动提交位移的方式。

 

 

另外对于消费消息重复的情况，业务自己保证幂等性, 保证只成功消费一次即可。

 

 

05 总结

 

 

这里，我们一起来总结一下这篇文章的重点。

 

 

1、从 Kafka 整体架构上概述了可能发生数据丢失的环节。

 

 

2、带你剖析了「消息传递语义」的概念， 确定了 Kafka 只对「已提交」的消息做「最大限度的持久化保证不丢失」。

 

 

3、带你剖析了 Producer、Broker、Consumer 三端可能导致数据丢失的场景以及具体的高可靠解决方案。