27高水位和leader epoch

1.leader epoch是如何在broker之间同步的
TODO

2.已经写入的消息不一定发送成功，消息发送成功的判断依据是什么？
高水位前的消息为已提交的消息，配置acks为all的生产者会等待ISR副本中的所有副本都同步了该消息才会认为消息已经成功提交。副本同步消息有时间延迟，如果生产者同步发送消息则会等待一段时间。

3.leader和follow副本同步存在错配，在这段高水位未同步的时间里如果接连发生follow和leader副本重启，则会造成消息丢失。leader epoch机制通过日志截断前先向leader获取leo来确定要不要截断。leadepoch的作用是fencing逻辑，确认从leader获取的leo是否是有效的（leo大于最新的leader epochoffset）？

4.为什么broker宕机重启后要进行日志截断操作？
因为即使消息写入到了磁盘上也不代表这条消息就提交成功了。未成功提交的消息及时写入了磁盘也要截断

5.leader epoch的作用是什么？
（1）保证在日志截断的时候不会因为出现因leader/follower接连宕机导致的不一致性。
（2）防止日志错乱
https://t1mek1ller.github.io/2020/02/15/kafka-leader-epoch/

6.leader epoch机制，重启回来的broker获取leader的leo时，leader挂了会发生什么？这套机制还能运行吗？
这套机制防止的是根据HW做日志截断出现数据不一致，不能防止任何情况下副本都正常工作

如果B重启回来，向A发起LeaderEpoch请求，这时候A挂了，会影响数据一致性吗？
不会，这时候A挂了，B就会选举为Leader，Leader不会进行日志截断操作。

可以参考
https://t1mek1ller.github.io/2020/02/15/kafka-leader-epoch/

7.文中leader epoch的作用的例子，follow副本重启回来后HW为1，后面是怎么将HW更新为2的？
走HW的更新机制，HW = max(HW, min (Remote-LEO1, Remote-LEO2))