每个kafka副本对象都持有2个重要的属性：日志末端位移LEO，高水印HW
Kafka对leader副本和follower副本的LEO更新机制是不同的，后面我们会详细讨论。
Kafka对leader副本和follower副本的hw值更新机制也是不同的。
消费者无法消费分区leader副本上那些位移大于分区hw的消息。分区hw就是leader副本的hw值。
关于LEO
2套follower副本LEO属性：一套LEO值保存在follower副本所在broker的缓存上；另一套LEO值保存在leader副本所在的broker的缓存上。
follwer副本的LEO：每写一条消息就+1
leader上的副本LEO：收到FETCH请求之后，先从自己的log中读取相应的数据，但是在给follower返回数据之前它先去更新follower的LEO
关于HW(时机+算法)
follower更新hw：follower更新hw发生在其更新LEO之后，一旦follower向log写完数据，它就会尝试更新HW值，具体的算法就是比较当前LEO值与FETCH响应中leader的HW值，取两者的小者作为新的HW值。
leader更新hw的时机：
1.副本成为leader时
2.broker出现崩溃导致副本被踢出ISR时
3.producer向leader副本写入消息时
4.leader处理followerFETCH请求时：首先会从底层的log读取数据，之后再尝试更新分区HW值。
如何更新：
当确定分区hw时，它会选出所有满足条件的副本，比较他们的LEO，并选择最小的LEO值作为HW值，这里的满足条件主要是指副本满足一下两个条件之一：
1.出于ISR中
2.副本LEO落后于leaderLEO的时长不大于replica.lag.time.max.ms参数值(默认时10秒)
特殊情况：
Hw值的更新通常需要另一轮FETCH请求才能完成，故这种设计在本质上是存在缺陷的。可能引起，备份数据丢失，备份数据不一致。
fetch请求没有新消息时返回什么？leader会更新leo吗。答：follower发送过来的FETCH请求因为无数据而暂时被寄存到leader端的purgatory中，待500毫秒后超时会强制完成。
leader宕机时hw之外的消息会丢失？
hw在第二轮刚开始的时候宕机，新leader的没更新hw，这个时候它本地没有LEO，怎么更新hw。 是不是需要一轮其他副本fetch请求之后才能确定hw，和生成本地leo缓存。
基于·水印备份机制的缺陷：hw过期
在0.11.0.0版本之前，kafka一直使用基于水印的备份机制
1.数据丢失
前提：min.insync.replicas=1
follower副本在重启后将leo截断至hw（为什么要截断）。此时在给leader发FETCH，若leader此时宕机那么被截断的那部分就丢失了.
2.数据不一致/数据离散
前提：min.insync.replicas=1
A leo=2 hw=2,B leo=1 hw=1；AB同时挂掉，B先重连并且写入一条消息hw=2，A再重启后发现hw与分区相同，会不作调整继续工作。
0.11.0.0版本解决之道
leader epoch取代hw，leader端多开辟一段内存区域专门保存leader的epoch信息。
所谓leader epoch，实际上是一对值，epoch表示leader的版本号，从0开始，当leader变更过1次，epoch就会加1，而offset则对应与该epoch版本的leader写入第一条消息的位移，假设存在两对值(0,0)和(1,120)那么表示第一个leader从位移0开始写入消息，供血了120条。
每个leader broker中会保存这样一个缓存，并定期写入一个检查点文件中，当leader写滴成log时，它会尝试更新整个缓存--如果这个leader首次写消息，则会在缓存中增加一个条目，否则就不做更新，而每次副本重新成为leader时会查询这部分混存，获取对应leader版本的位移，这就不会发生数据不一致和丢失的情况。
这里offsetsForLeaderEpochRequest如果A在响应之前就宕机了怎么办