kafka处理消息写入和备份的全流程

1. Base Offset：是起始位移，该副本中第一条消息的offset，如下图，这里的起始位移是0，如果一个日志文件写满1G后（默认1G后会log rolling），这个起始位移就不是0开始了。
2. HW（high watermark）：副本的高水印值；
3. LEO（log end offset）：日志末端位移，代表日志文件中下一条待写入消息的offset；

 

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就先更新了。（简而言之：remoteLEO 更新前，leader都会再去fetch请求follower副本的 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解决了。

 

 

leader 故障：

leader 发生故障后，会从副本同步队列ISR 协会去找一个新的leader ，然后他下面的所有员工小弟就必须听自己

的话，以为我为HW为标准，大于我的都个字截取掉。然后继续同步数据；

 

follower故障：

当故障后会被ISR协会踢出去，待恢复后，首先读本地磁盘的log记录，高于HW部分截掉，然后从HW开始向leader进行同步，等到追上了leader后，才能加入ISR协会；