kafka(八)——AR、ISR、HW和LEO

概念

AR

bash 复制代码
即Assigned Replicas,分区中所有副本的统称,leader副本+follower副本。

ISR

bash 复制代码
即In-Sync Replicas,同步副本集合,表示当前与主副本保持同步的副本集合。

当主副本故障时,kafka会从ISR中选出新的主副本执行工作。

当从副本因网络延迟、 节点故障等原因导致拉取偏移量落后过多,超出阈值时,主副本会将其从ISR中移除。当从副本恢复同步后,再次将其加入ISR。

主副本持续监控每个从副本的拉取偏移量,将其与自身的最新消息偏移量(LEO)进行比较。若从副本的拉取偏移量与主副本相差不超过一定阈值(由replica.lag.time.max.ms参数控制),则认为该主副本处于同步状态,将其纳入ISR。

OSR

bash 复制代码
即Out-of-Sync Replicas,异步副本集合,表示当前未与主副本保持同步的副本集合。

AR = ISR + OSR

图解:

HW

bash 复制代码
即High Watermark,高水位,标识了一个特定的消息偏移量(offset),消费者只能拉取到这个 offset 之前的消息。

取 partition 对应的 ISR 中 最小的 LEO 作为 HW,消费者最多只能消费到 HW 所在的位置上一条信息。(类似于木桶理论)

图解:

LEO

bash 复制代码
即Log End Offset,日志末尾偏移量,代表当前日志文件中末尾下一条待写消息的 offset。

当生产者向分区中写入消息时,它会将该消息的偏移量记录在LEO中。

消费者从分区中读取消息时,它可以通过LEO来判断是否已经读取了所有的消息。

图解:

流程

  1. 消息写入:将生产的5、6消息存储至Leader副本。
  1. 写入Leader副本成功,Follower副本向Leader副本同步数据。
  1. Follower副本的消费效率不同,HW也随着变化。
  1. 所有生产数据同步成功的情况如下:

总结:

  • Leader副本将数据写至本地磁盘;
  • Leader副本更新LEO;
  • follower副本发送同步数据请求,携带自身的 LEO;
  • leader副本更新本地保存的其它副本的 LEO;
  • leader 副本尝试更新 ISR 列表;
  • leader 副本更新 HW;
  • leader 副本给 follower 副本返回数据,携带 leader 副本的 HW 值;
  • follower 副本接收响应并写入数据,更新自身 LEO;
  • follower 副本更新本地的 HW 值;

副本故障

Leader副本故障

  1. Leader副本与Follower副本数据未同步完成。
  1. Leader副本发生故障,从isr中选出一个新的Leader副本,为保证多个副本之间的数据一致性,其余的Follower会先将各自的log文件高于HW的部分截掉,然后从新的Leader同步数据。

    说明:这种情况下不能保证数据不丢失。

Follower副本故障

follower副本发生故障会被临时踢出ISR,待follower副本恢复后,follower副本会读取本地磁盘上次记录的HW,将log文件高于HW的部分截取掉,从HW开始向leader副本进行同步,等待该follower副本的LEO大于该Partition的HW,即follower副本追上leader副本之后,就可以重新加入ISR。

配置

  • acks(生产者参数)
bash 复制代码
0:生产者发送过来的数据,不需要等数据落盘应答,即不需要Leader副本和Follower副本数据落盘。
1:生产者发送过来的数据,Leader副本收到数据并写入磁盘成功后应答。
-1(all):默认值。生产者发送过来的数据,Leader副本和isr队列里面的所有follower副本收到数据并写入磁盘成功后应答。
  • topic副本数
bash 复制代码
# 默认2副本
default.relication.factor=2
  • 副本同步复制最大延迟时间
bash 复制代码
# 默认30s
replica.lag.time.max.ms=30000
  • 消息提交成功的最小isr的数量
bash 复制代码
# 表示一个topic至少需要多少个副本出于isr中,才认为消息写入成功
# 该值过大,增加数据可靠性,写入性能降低;该值过小,写入速度增加,数据可靠性降低;
min.insync.replicas=2
  • 副本拉取线程数
bash 复制代码
# 默认是1。副本拉取线程数,这个参数占总核数的50%的1/3
num.replica.fetchers=1
相关推荐
敖正炀14 小时前
高并发系统的降级预案与容错策略
分布式·架构
敖正炀14 小时前
稳定性监控与告警体系:SLI/SLO/SLA 实践
分布式·架构
敖正炀15 小时前
故障演练与混沌工程:ChaosBlade 到 Litmus
分布式·架构
敖正炀15 小时前
全链路压测与容量规划方法论
分布式·架构
敖正炀15 小时前
限流算法深度与 Guava/Sentinel 源码:从单机令牌桶到分布式滑动窗口的流量防护体系
分布式·架构
山屿落星辰19 小时前
hixl - 让分布式训练“零拷贝“通信
分布式
逍遥德21 小时前
SpringBoot自带TaskScheduler 接口使用详解:(02)微服务多实例模式下,爆发任务重复执行问题
spring boot·分布式·后端·微服务·中间件
Devin~Y21 小时前
互联网大厂 Java 面试实录:JVM、Spring Boot、MyBatis、Redis、Kafka、Spring AI、K8s 全链路追问小Y
java·jvm·spring boot·redis·kafka·mybatis·spring security
倒流时光三十年1 天前
第12篇 Rebalance 深度解析
spring boot·kafka
Solis程序员1 天前
基于 Outbox 事务表 + Canal 监听+kafka+多级缓存:高并发社交关注系统全链路架构设计
分布式·kafka·linq