kafka到底会不会丢消息？

前言

网上很多文章都有讲解Kafka是如何保证不丢失消息的，但是真正的不丢消息吗？特别是当我看到broker写消息是写入内存中，也就是操作系统页缓存中，我就在想，如果这个时候物理机重启，内存东西都没了，消息不久没有了吗，于是带着这个疑问去找了很多资料，我们今天就谈谈到底会不会丢消息。

丢消息的三个场景

• 1、生产者发消息给Kafka Broker

• 2、Kafka Broker 消息同步和持久化

• 3、Kafka Broker 将消息传递给消费者

1、生产者发消息给Kafka Broker

生产者发消息给broker后，消息写入Leader后，Follower是主动与Leader进行同步，然后发ack告诉生产者收到消息了。这里Kafka通过配置request.required.acks属性来确认消息的生产，一共有3种模式：

• 0表示不进行消息接收是否成功的确认；不能保证消息是否发送成功，生成环境基本不会用。

• 1表示当Leader接收成功时确认；只要Leader存活就可以保证不丢失，保证了吞吐量。

• -1或者all表示Leader和Follower都接收成功时确认；可以最大限度保证消息不丢失，但是吞吐量低。

kafka producer 的参数acks 的默认值为1，所以默认的producer级别是at least once，并不能exactly once。丢消息的情况下，有2种场景：

• 如果acks配置为0，发生网络抖动消息丢了，生产者不校验ACK自然就不知道丢了。
• 如果acks配置为1保证leader不丢，但是如果leader挂了，恰好选了一个没有ACK的follower，那也丢了。

all：保证leader和follower不丢，但是如果网络拥塞，没有收到ACK，生产者会有重复发的问题，但消息不会丢。

2、Kafka Broker 消息同步和持久化

操作系统本身有一层缓存，叫做 Page Cache，当往磁盘文件写入的时候，系统会先将数据流写入缓存中，至于什么时候将缓存的数据写入文件中是由操作系统自行决定。

• Kafka通过多分区多副本机制中已经能最大限度保证数据不会丢失，如果数据已经写入系统 cache 中但是还没来得及刷入磁盘，此时突然机器宕机或者掉电那就丢了，当然这种情况很极端。

3、Kafka Broker 将消息传递给消费者

消费者通过pull模式主动的去 kafka 集群拉取消息，与producer相同的是，消费者在拉取消息的时候也是找leader分区去拉取。并且消费消息的时候会把消息commit掉，但是commit方式有2种：

• commit掉消息后，再处理，这个时候处理逻辑异常了，消息就被你处理掉了，默认就是被消费了，此时消息并没有真正被处理，可以是消息丢失的一个场景。
• 先消费，再commit，这样消息处理失败，也不会commit，但是会有重复消费，没有丢消息。

参考博客

刨根问底，kafka 到底会不会丢消息