kafka入门之broker-水印和leader epoch

2019/07/20 20:24
阅读数 104

 每个kafka副本对象都持有2个重要的属性:日志末端位移LEO,高水印HW

Kafka对leader副本和follower副本的LEO更新机制是不同的,后面我们会详细讨论。

Kafka对leader副本和follower副本的hw值更新机制也是不同的。

消费者无法消费分区leader副本上那些位移大于分区hw的消息。分区hw就是leader副本的hw值。

关于LEO

2套follower副本LEO属性:一套LEO值保存在follower副本所在broker的缓存上;另一套LEO值保存在leader副本所在的broker的缓存上。

follwer副本的LEO:每写一条消息就+1

leader上的副本LEO:收到FETCH请求之后,先从自己的log中读取相应的数据,但是在给follower返回数据之前它先去更新follower的LEO

关于HW(时机+算法)

follower更新hw:follower更新hw发生在其更新LEO之后,一旦follower向log写完数据,它就会尝试更新HW值,具体的算法就是比较当前LEO值与FETCH响应中leader的HW值,取两者的小者作为新的HW值。

leader更新hw的时机:

1.副本成为leader时

2.broker出现崩溃导致副本被踢出ISR时

3.producer向leader副本写入消息时

4.leader处理followerFETCH请求时:首先会从底层的log读取数据,之后再尝试更新分区HW值。

如何更新:

当确定分区hw时,它会选出所有满足条件的副本,比较他们的LEO,并选择最小的LEO值作为HW值,这里的满足条件主要是指副本满足一下两个条件之一:

1.出于ISR中

2.副本LEO落后于leaderLEO的时长不大于replica.lag.time.max.ms参数值(默认时10秒)

特殊情况:

Hw值的更新通常需要另一轮FETCH请求才能完成,故这种设计在本质上是存在缺陷的。可能引起,备份数据丢失,备份数据不一致。

fetch请求没有新消息时返回什么?leader会更新leo吗。答:follower发送过来的FETCH请求因为无数据而暂时被寄存到leader端的purgatory中,待500毫秒后超时会强制完成。

leader宕机时hw之外的消息会丢失?

hw在第二轮刚开始的时候宕机,新leader的没更新hw,这个时候它本地没有LEO,怎么更新hw。 是不是需要一轮其他副本fetch请求之后才能确定hw,和生成本地leo缓存。

基于·水印备份机制的缺陷:hw过期

在0.11.0.0版本之前,kafka一直使用基于水印的备份机制

1.数据丢失

前提:min.insync.replicas=1

follower副本在重启后将leo截断至hw(为什么要截断)。此时在给leader发FETCH,若leader此时宕机那么被截断的那部分就丢失了.

 

2.数据不一致/数据离散

前提:min.insync.replicas=1

A leo=2 hw=2,B leo=1 hw=1;AB同时挂掉,B先重连并且写入一条消息hw=2,A再重启后发现hw与分区相同,会不作调整继续工作。

0.11.0.0版本解决之道

leader epoch取代hw,leader端多开辟一段内存区域专门保存leader的epoch信息。

所谓leader epoch,实际上是一对值,epoch表示leader的版本号,从0开始,当leader变更过1次,epoch就会加1,而offset则对应与该epoch版本的leader写入第一条消息的位移,假设存在两对值(0,0)和(1,120)那么表示第一个leader从位移0开始写入消息,供血了120条。

每个leader broker中会保存这样一个缓存,并定期写入一个检查点文件中,当leader写滴成log时,它会尝试更新整个缓存--如果这个leader首次写消息,则会在缓存中增加一个条目,否则就不做更新,而每次副本重新成为leader时会查询这部分混存,获取对应leader版本的位移,这就不会发生数据不一致和丢失的情况。

这里offsetsForLeaderEpochRequest如果A在响应之前就宕机了怎么办

 

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部