Kafka持久原理

zhuanlan.zhihu.com/p/345244952

Partition就是个目录，里面有很多segment

segment包含index、log文件

Kafka丢数据的位置

zhuanlan.zhihu.com/p/459610418

Producer端

两种可能:

1. Producer端要攒够一定条数或超时，才会发数据给Kafka Broker，所以存在还没发送就挂了丢数据的情况。

导致 Producer 端消息没有发送成功有以下原因：

网络原因： 由于网络抖动导致数据根本就没发送到 Broker 端。

数据原因： 消息体太大超出 Broker 承受范围而导致 Broker 拒收消息。

1. 优化策略导致丢数据 Producer 端配置 request.required.acks 如下图的3种配置都有可能丢数据
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 的情况了。

Broker端

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

Consumer 端

Consumer处理消息，并标记消息已经被消费，提交 Offset 记录，中间可能丢数据：

可能使用的「自动提交 Offset 方式」
拉取消息后「先提交 Offset，后处理消息」，如果此时处理消息的时候异常宕机，由于 Offset 已经提交了, 待 Consumer 重启后，会从之前已提交的 Offset 下一个位置重新开始消费，之前未处理完成的消息不会被再次处理，对于该 Consumer 来说消息就丢失了。

重复消费

拉取消息后「先处理消息，在进行提交 Offset」，如果此时在提交之前发生异常宕机，由于没有提交成功 Offset，待下次 Consumer 重启后还会从上次的 Offset 重新拉取消息，不会出现消息丢失的情况，但是会出现重复消费的情况，这里只能业务自己保证幂等性。