KAFKA 服务端日志LEO和HW机制带来的问题及其解决方案

一、KAFKA 服务端日志LEO和HW带来的问题

KAFKA 服务端日志LEO和HW无论是leader还是follow的HW更新都需要第二轮fetch才能完成，若在第二轮fetch中follow或leader崩溃则有可能带来数据丢失或数据不一致问题。

1.1 数据丢失

该主题有两个副本，其中A是leader，B是follow。设min.insync.replicas=1 and acks=-1则当生产者发送信息后只要leader A 写入到底层，此时kafka就好通知生产者发送成功。

按照现有HW逻辑，fetch第一阶段主要完成leader和follow LEO的更新第二阶段才是HW的更新。在第二阶段首先是leader HW的更新，HW=min(leader leo,follow leo)=2，读取数据后发送给follow B，B收到后正准备更新HW=min(leo=2.leader HW=2)=2但此时B所在broker崩溃。B重启后，因为HW没有更新成功仍然是1故会将LEO截断则LEO=1，offset=1的数据从日志文件删掉。B重启后向A发fetch请求，此时A正好也宕机。则B成为Leader。

当A重启后，按照leader B的hw，A也会进行截断，A上leo=hw=1。最终原来offset=1上的消息从这两个副本都删除，数据永远丢失。

1.2 数据不一致