Kafka到底会不会丢数据？( 二 ) _Kafka

其次是「最大限度的持久化保证不丢失」，也就是说 Kafka 并不能保证在任何情况下都能做到数据不丢失。即 Kafka 不丢失数据是有前提条件的。假如这时你的消息保存在 N 个 Broker 上，那么前提条件就是这 N 个 Broker 中至少有1个是存活的，就可以保证你的消息不丢失。

也就是说 Kafka 是能做到不丢失数据的，只不过这些消息必须是「已提交」的消息，且还要满足一定的条件才可以。
了解了 Kafka 消息传递语义以及什么情况下可以保证不丢失数据，下面我们来详细剖析每个环节为什么会丢数据，以及如何最大限度避免丢失数据。
三、消息丢失场景剖析
1.Producer 端丢失场景剖析
在剖析 Producer 端数据丢失之前，我们先来了解下 Producer 端发送消息的流程，对于不了解 Producer 的读者们，可以查看聊聊 Kafka Producer 那点事。
消息发送流程如下：

文章插图

首先我们要知道一点就是 Producer 端是直接与 Broker 中的 Leader Partition 交互的，所以在 Producer 端初始化中就需要通过 Partitioner 分区器从 Kafka 集群中获取到相关 Topic 对应的 Leader Partition 的元数据。
待获取到 Leader Partition 的元数据后直接将消息发送过去。
Kafka Broker 对应的 Leader Partition 收到消息会先写入 Page Cache，定时刷盘进行持久化（顺序写入磁盘）。
Follower Partition 拉取 Leader Partition 的消息并保持同 Leader Partition 数据一致，待消息拉取完毕后需要给 Leader Partition 回复 ACK 确认消息。
待 Kafka Leader 与 Follower Partition 同步完数据并收到所有 ISR 中的 Replica 副本的 ACK 后，Leader Partition 会给 Producer 回复 ACK 确认消息。

根据上图以及消息发送流程可以得出：Producer 端为了提升发送效率，减少IO操作，发送数据的时候是将多个请求合并成一个个 RecordBatch，并将其封装转换成 Request 请求「异步」将数据发送出去（也可以按时间间隔方式，达到时间间隔自动发送），所以 Producer 端消息丢失更多是因为消息根本就没有发送到 Kafka Broker 端。
导致 Producer 端消息没有发送成功有以下原因：

网络原因：由于网络抖动导致数据根本就没发送到 Broker 端。
数据原因：消息体太大超出 Broker 承受范围而导致 Broker 拒收消息。

另外 Kafka Producer 端也可以通过配置来确认消息是否生产成功：

文章插图
在 Kafka Producer 端的 acks 默认配置为1，默认级别是 at least once 语义, 并不能保证 exactly once 语义。
既然 Producer 端发送数据有 ACK 机制, 那么这里就可能会丢数据的!!!

acks = 0：由于发送后就自认为发送成功，这时如果发生网络抖动， Producer 端并不会校验 ACK 自然也就丢了，且无法重试。
acks = 1：消息发送 Leader Parition 接收成功就表示发送成功，这时只要 Leader Partition 不 Crash 掉，就可以保证 Leader Partition 不丢数据，但是如果 Leader Partition 异常 Crash 掉了， Follower Partition 还未同步完数据且没有 ACK，这时就会丢数据。
acks = -1 或者 all：消息发送需要等待 ISR 中 Leader Partition 和所有的 Follower Partition 都确认收到消息才算发送成功, 可靠性最高, 但也不能保证不丢数据,比如当 ISR 中只剩下 Leader Partition 了, 这样就变成 acks = 1 的情况了。

2.Broker 端丢失场景剖析
接下来我们来看看 Broker 端持久化存储丢失场景，对于不了解 Broker 的读者们，可以先看看聊聊 Kafka Broker 那点事，数据存储过程如下图所示：

文章插图
Kafka Broker 集群接收到数据后会将数据进行持久化存储到磁盘，为了提高吞吐量和性能，采用的是「异步批量刷盘的策略」，也就是说按照一定的消息量和间隔时间进行刷盘。首先会将数据存储到「PageCache」中，至于什么时候将 Cache 中的数据刷盘是由「操作系统」根据自己的策略决定或者调用 fsync 命令进行强制刷盘，如果此时 Broker 宕机 Crash 掉，且选举了一个落后 Leader Partition 很多的 Follower Partition 成为新的 Leader Partition，那么落后的消息数据就会丢失。
既然 Broker 端消息存储是通过异步批量刷盘的，那么这里就可能会丢数据的!!!