上文我们已经学到，

• 一个Topic（主题）会有多个Partition（分区）
• 为了保证高可用，每个分区有多个Replication（副本）
• 副本分为Leader 和 Follower 两个角色，Leader副本对外提供读写服务，Follower 从Leader同步数据
• 当Leader副本挂掉，从ISR中选举一个Follower副本成为新的Leader对外继续提供服务
• 那么就要保证分区各副本间数据一致性

图1：

见上图，先来熟悉一下

• 已提交，Leader副本已经被ISR中所有Follower 都同步的消息
• 未提交，Leader已经写入，还没有被Follower同步的消息
• 对Consumer（消费者）而言，已提交的消息都可以拿到
• Leader 和 Follower副本上都有HW 和 LEO
• Leader副本除了自己的LEO，还存Follower的LEO（Remote LEO）

HW （High WaterMarker） 高水位

图2：

高水位可以理解为一个横切面，存储的也是Offset(位移)值，
拉齐分区ISR所有副本已经写入的消息，保证HW前的消息你有我有全都有啊，水桶原理

这里要注意，所有副本指的是ISR列表中的同步副本，OSR中同步慢的副本不管
为啥只管ISR列表，不管OSR列表中的副本呢？
这也就是为啥要搞HW 和 LEO 的原因，搞HW就是为了当Leader宕机了，会从ISR列表中选举一个Follower成为新的Leader继续对外提供服务，来实现高可用，而HW能保证任意一个Follower都包含对消费者可见的所有数据，实现数据的可靠性
而OSR是同步过慢的副本，选举也不选它，所以记录HW值也没必要管OSR列表

LEO （Log End Offset） 日志末端位移

就是下一个消息要写入的Offset（位移），
如上图1，当前副本最后一条消息的位移是13，下一个消息写入14位置，该副本的LEO值就是14

Follower 副本何时更新LEO呢？

以图2 中为例：
Leader 的LEO = 14
Follower1 的 LEO = 12
Follower2 的 LEO = 8

• 对于Leader副本来说，每次写入消息，都会更新LEO的值
• Follower 副本不停地向Leader副本发送Fetch请求，一旦获取数据后就写入log(日志)文件中进行备份，同时更新LEO值
• 其实Follower跟Leader一样，写入数据后就更新自己的LEO值

那么Leader 端的Follower的LEO 什么时候更新呢？

• 当Leader接收到Follower发起的Fetch请求
• 先从Log文件中读取数据
• 先更新Leader中存储的Follower的LEO
• 再将数据返回给Follower
• 这里会不会存在Leader更新了Follower的LEO，但是Follower实际并没有收到返回的消息，而造成Follower 所在broker 和 Leader所在broker存的LEO值不一致呢？

Follower 何时更新HW呢？

以图2 中为例：
Leader 、Follower1 、 Follower2 的 HW = 7

• Follower写入数据后，会更新自己的LEO值，然后就尝试更新自己的HW值
• Follower的HW值是怎么算的呢？
  • 是根据自己当前LEO值与Leader返回的HW值比较，去较小值作为HW更新
  • 这很好理解，Leader中记录的HW是所有副本HW最小的值，也就是同步最慢的那个副本的LEO，每个副本都需要知道这个事，自己不是最小那就记别人的值

Leader 何时更新HW呢？

• Leader中存储的HW就是整个分区的HW，直接影响消息对消费者的可见性
• Leader更新HW有4中情况
  • Leader接收生产者发送过来的消息，写入文件后，检查是否需要更新HW
  • Follower副本选举成为新的Leader是，Kafka会尝试去更新分区HW
  • Broker崩溃，导致副本被踢出ISR，Kafka会检查分区HW是否有被更新的必要
  • Leader处理Follower的Fetch请求是，先从Log读取数据，然后尝试跟新HW值
• 正常情况下就是2种： leader处理producer请求，leader处理follower的fetch请求

Leader 的HW值是怎么算的呢？

• 先选出所有满足条件的副本，ISR同步副本
• 比较它们的LEO（包括leader的LEO）
• 选择最小的LEO值作为HW

感觉有点迷糊？ 我们再来一篇举个栗子，掰BoBo说陷一下子，跟住奥~

---

** 都说kafka最厉害的地方是他的设计思想，果然有很多精妙之处啊**