Kafka

Kafka

HW (HighWaterMark) 和 LEO (Last End Offset)

1. LEO：每个最后一个offset即为该副本的LEO
   HW：ISR和副本leo落后leader LEO的时长不大于replica.lag.time.max.ms参数值(默认是10s)的副本中最小的LEO即为该分区的HW，用来判定副本的备份进度，HW以外的消息不被消费者可见
2. leader持有的HW即为分区的HW,同时leader所在broker还保存了所有follower副本的leo
   1. 关系：leader的leo >= follower的leo >= leader保存的follower的leo >= leader的hw >= follower的hw
   2. 原理：上面关系反应出各个值的更新逻辑的先后
3. LEO的更新时间
   1. follower的leo更新时间：每当follower副本写入一条消息时，leo值会被更新
   2. leader端的follower副本的leo更新时间：当follower从leader处fetch消息时，leader获取follower的fetch请求中offset参数，更新保存在leader端follower的leo
   3. leader本身的leo的更新时间：leader向log写消息时
4. HW的更新时间
   1. follower更新HW：follower更新HW发生在其更新完LEO后，即当follower写完数据后，会比较当前LEO(已更新)与fetch响应中leader的HW值，取最小值
   2. leader副本更新HW：
      1. 故障情况：
         1. 当某个副本被选为分区的leader时
         2. 当broker故障导致相关副本被踢出ISR时
      2. 正常情况：
         1. follower发送fetch请求在leader处理完producer请求之后
            1. leader处理完消息，还未收到fetch请求时，leader会比较自己的leo值和remote leo值，一般最小值依然是与当前hw值相同，不做更新
            2. leader处理完消息后，收到fetch请求，根据fetch请求中follower携带的leo值更新其保存的remote leo，然后开始比对leo值，取最小值作为HW进行更新，并将fetch请求的数据和更新后的HW返回给follower，然后follower将数据写入log，并更新自己的HW
         2. follower发送fetch请求在leader处理完producer请求之前
            1. 如果follower的fetch请求没有更新的数据，则请求会在被leader暂存在purgatory中，暂存时长默认为500ms（replica.fetch.wait.max.ms）
            2. 如果fetch请求缓存期间，leader处理完producer请求（数据写入log,并更新leader leo），则会唤醒purgatory中寄存的fetch请求
            3. 接下来流程如（1）
5. 节点故障恢复
   1. follower故障再次恢复后，从磁盘读取hw的值并从hw开始剔除后面的消息，并同步leader消息
   2. leader故障后，新当选的leader的hw作为新的分区hw，其余节点按照此hw进行剔除数据，并重新同步
   3. 上述根据hw进行数据恢复仅能保证数据的一致性，但是会出现数据丢失和重复的情况
   4. leader epoch在0.11版本引入来解决hw的数据丢失和重复的问题
   5. leader epoch实际为一对值（epoch, offset），epoch表示leader版本号，offset为对应版本leader的leo