Kafka-LEO和HW概念及更新流程

记录下和kafka相关的LEO和HW的内容，文中很多理解参考文末书籍还有某前辈。

LEO&HW基本概念

1. Base Offset：是起始位移，该副本中第一条消息的offset，如下图，这里的起始位移是0，如果一个日志文件写满1G后（默认1G后会log rolling），这个起始位移就不是0开始了。
2. HW（high watermark）：副本的高水印值，replica中leader副本和follower副本都会有这个值，通过它可以得知副本中已提交或已备份消息的范围，leader副本中的HW，决定了消费者能消费的最新消息能到哪个offset。如下图所示，HW值为8，代表offset为[0,8]的9条消息都可以被消费到，它们是对消费者可见的，而[9,12]这4条消息由于未提交，对消费者是不可见的。注意HW最多达到LEO值时，这时可见范围不会包含HW值对应的那条消息了，如下图如果HW也是13，则消费的消息范围就是[0,12]。
3. LEO（log end offset）：日志末端位移，代表日志文件中下一条待写入消息的offset，这个offset上实际是没有消息的。不管是leader副本还是follower副本，都有这个值。当leader副本收到生产者的一条消息，LEO通常会自增1，而follower副本需要从leader副本fetch到数据后，才会增加它的LEO，最后leader副本会比较自己的LEO以及满足条件的follower副本上的LEO，选取两者中较小值作为新的HW，来更新自己的HW值。

LEO&HW更新流程

LEO和HW的更新，需要区分leader副本和follower副本，两者上的更新情况不一样，整体参考下图简单示例。

LEO

包括leader副本和follower副本。

leader LEO：leader的LEO就保存在其所在的broker的缓存里，当leader副本log文件写入消息后，就会更新自己的LEO。

remote LEO和follower LEO：remote LEO是保存在leader副本上的follower副本的LEO，可以看出leader副本上保存所有副本的LEO，当然也包括自己的。follower LEO就是follower副本的LEO，因此follower相关的LEO需要考虑上面两种情况。

• case 1：如果是remote LEO，更新前leader需要确认follower的fetch请求包含的offset，这个offset就是follower副本的LEO，根据它对remote LEO进行更新。如果更新时尚未收到fetch请求，或者fetch请求在请求队列中排队，则不做更新。可以看出在leader副本给follower副本返回数据之前，remote LEO就先更新了。
• case 2：如果是follower LEO，它的更新是在follower副本得到leader副本发送的数据并随后写入到log文件，就会更新自己的LEO。

HW

包括leader副本和follower副本。

leader HW：它的更新是有条件的，参考书籍中给出了四种情况，如下是其中的一种，就是producer向leader副本写消息的情况，当满足四种情况之一，就会触发HW尝试更新。如下图所示更新时会比较所有满足条件的副本的LEO，包括自己的LEO和remote LEO，选取最小值作为更新后的leader HW。

四种情况如下，其中最常见的情况就是前两种。

1.producer向leader写消息，会尝试更新。
2.leader处理follower的fetch请求，先读取log数据，然后尝试更新HW。
3.副本成为leader副本时，会尝试更新HW。
4.broker崩溃可能会波及leader副本，也需要尝试更新。

follower HW：更新发生在follower副本更新LEO之后，一旦follower向log写完数据，它就会尝试更新HW值。比较自己的LEO值与fetch响应中leader副本的HW值，取最小者作为follower副本的HW值。可以看出，如果follower的LEO值超过了leader的HW值，那么follower HW值是不会超过leader HW值的。

更新流程示例分析

以下是参考《apache kafka实战》的整理。

前提条件：考虑一个主题，只有一个分区，两个副本的情况，并且刚开始都没有任何消息在log日志文件。

在考虑fetch请求时，需要考虑两种情况，接下来就只考虑第二种情况，第一种情况也可以参考第二种情况。

1. producer暂时无法响应follower partition的请求，如没有数据可以返回，这时fetch请求会缓存在一个叫做purgatory的对象里（请求不会无限期缓存，默认500ms）。在缓存期间，如果producer发送PRODUCE请求，则被唤醒，接下来会正常处理fetch请求。
2. producer正常响应follower partition的请求。

下面分析第二种情况，即producer正常响应follower的情况。

当leader副本接受到了producer的消息，并且此时没有follower副本fetch请求，在这样的前提下，它会先做如下操作。

1. 写入消息到log日志文件，更新leader LEO为1。
2. 尝试更新remote LEO，由于没有fetch请求，因此它是0，不需要更新。
3. 做min(leader LEO,remote LEO)的计算，结果为0，这样leader HW无需更新，依然是0。

第一次fetch请求，分leader端和follower端：

leader端：

1. 读取底层log数据。
2. 根据fetch带过来的offset=0的数据（就是follower的LEO，因为follower还没有写入数据，因此LEO=0），更新remote LEO为0。
3. 尝试更新HW，做min(leader LEO,remote LEO)的计算，结果为0。
4. 把读取到的log数据，加上leader HW=0，一起发给follower副本。

follower端：

1. 写入数据到log文件，更新自己的LEO=1。
2. 更新HW，做min(leader HW,follower LEO)的计算，由于leader HW=0，因此更新后HW=0。

可以看出，第一次fetch请求后，leader和follower都成功写入了一条消息，但是HW都依然是0，对消费者来说都是不可见的，还需要第二次fetch请求。

第二次fetch请求，分leader端和follower端：

leader端：

1. 读取底层log数据。
2. 根据fetch带过来的offset=1的数据（上一次请求写入了数据，因此LEO=1），更新remote LEO为1。
3. 尝试更新HW，做min(leader LEO,remote LEO)的计算，结果为1。
4. 把读取到的log数据（其实没有数据），加上leader HW=1，一起发给follower副本。

follower端：

1. 写入数据到log文件，没有数据可以写，LEO依然是1。
2. 更新HW，做min(leader HW,follower LEO)的计算，由于leader HW=1，因此更新后HW=1。

这个时候，才完成数据的写入，并且分区HW（分区HW指的就是leader副本的HW）更新为1，代表消费者可以消费offset=0的这条消息了，上面的过程就是kafka处理消息写入和备份的全流程。

最后，使用HW来记录消息在副本中提交或备份的进度，其实是存在缺陷的，在kafka 0.11.0.0后的版本中，使用leader epoch解决了。由于水平有限，先不深究了，后续如有需要再参考文末书籍内容学习。

以上，理解不一定正确，学习就是一个不断认识和纠错的过程。

4.4清明节，珍惜当下，感恩生命！

参考博文：

（1）《Apache Kafka实战》