大数据-Kafka（九）

                                        大数据-Kafka（九）

kafka内核原理

ISR机制

光是依靠多副本机制能保证Kafka的高可用性，但是能保证数据不丢失吗？

不行，因为如果leader宕机，但是leader的数据还没同步到follower上去，此时即使选举了follower作为新的leader，当时刚才的数据已经丢失了。

ISR是：in-sync replica，就是跟leader partition保持同步的follower partition的数量，只有处于ISR列表中的follower才可以在leader宕机之后被选举为新的leader，因为在这个ISR列表里代表他的数据跟leader是同步的。

如果要保证写入kafka的数据不丢失，首先需要保证ISR中至少有一个follower，其次就是在一条数据写入了leader partition之后，要求必须复制给ISR中所有的follower partition，才能说代表这条数据已提交，绝对不会丢失，这是Kafka给出的承诺。

HW&LEO原理

• LEO

last end offset，日志末端偏移量，标识当前日志文件中下一条待写入的消息的offset。举一个例子，若LEO=10，那么表示在该副本日志上已经保存了10条消息，位移范围是[0，9]。

• HW

Highwatermark，俗称高水位，它标识了一个特定的消息偏移量（offset），消费者只能拉取到这个offset之前的消息。任何一个副本对象的HW值一定不大于其LEO值。

小于或等于HW值的所有消息被认为是“已提交的”或“已备份的”。HW它的作用主要是用来判断副本的备份进度。

下图表示一个日志文件，这个日志文件中只有9条消息，第一条消息的offset（LogStartOffset）为0，最有一条消息的offset为8，offset为9的消息使用虚线表示的，代表下一条待写入的消息。日志文件的 HW 为6，表示消费者只能拉取offset在 0 到 5 之间的消息，offset为6的消息对消费者而言是不可见的。

leader持有的HW即为分区的HW,同时leader所在broker还保存了所有follower副本的leo

（1）关系：leader的leo >= follower的leo >= leader保存的follower的leo >= leader的hw >= follower的hw

（2）原理：上面关系反应出各个值的更新逻辑的先后 

LEO的更新机制

注意：follower副本的LEO保存在2个地方。

（1）follower副本所在的broker缓存里。

（2）leader所在broker的缓存里，也就是leader所在broker的缓存上保存了该分区所有副本的LEO。

• follower更新LEO

（1）follower的leo更新时间

每当follower副本写入一条消息时，leo值会被更新。

（2）leader端的follower副本的leo更新时间

当follower从leader处fetch消息时，leader获取follower的fetch请求中offset参数，更新保存在leader端follower的leo。

• leader更新LEO

（1）leader本身的leo的更新时间：leader向log写消息时。

更新HW的机制

• follower更新HW

follower更新HW发生在其更新完LEO后，即follower向log写完数据，它就会尝试更新HW值。具体算法就是比较当前LEO(已更新)与fetch响应中leader的HW值，取两者的小者作为新的HW值。

• leader更新HW

leader更新HW的时机

（1）producer 向 leader 写消息时
（2）leader 处理 follower 的 fetch 请求时
（3）某副本成为leader时
（4）broker 崩溃导致副本被踢出ISR时

leader更新HW的方式

当尝试确定分区HW时，它会选出所有满足条件的副本，比较它们的LEO（当然也包括leader自己的LEO），并选择最小的LEO值作为HW值。

这里的满足条件主要是指副本要满足以下两个条件之一：

（1）处于ISR中

（2）副本LEO落后于leader LEO的时长不大于replica.lag.time.max.ms参数值（默认值是10秒），或者落后Leader的条数超过预定值replica.lag.max.messages（默认值是4000）。

此博文仅供学习参考，如有错误欢迎指正。

上一篇《大数据-Kafka（八）》

下一篇《大数据-Kafka（十）》