消息队列：Kafka副本机制和Offset管理

Kafka副本同步机制、延迟下线处理、offset存储、提交方式

Kafka的副本机制

  • LEO：每个副本都有一个LEO，即当前副本的最大的消息offset；
  • HW（High Watermark）：消费者只能看到HW以下的数据，防止宕机后，消息不一致；
  • AR：Kafka每个分区都有一组AR，代表所有副本的集合，包括主副本和备份副本，AR = ISR + OSR；
  • ISR：与Leader保持同步的Follower集合；作为Leader的候选者；
  • OSR：与Leader副本同步时，延迟过多的副本集合；可能是宕机后重新上线，还未完成offset同步的副本；

相关配置：

  • min.insync.replicas
    ：ISR最小副本数量，默认1
  • replica.lag.time.max.ms
    ：在这个时间内，没有追上Leader最新消息的副本，将被移除ISR；
  • replica.lag.max.messages
    ：已经在0.9x版本被移除，不再以落后的副本数作为ISR参考；

副本间的数据同步

  1. Leader在处理写请求时，会对数据进行落盘操作；
  2. Follower会向Leader批量拉取消息，Leader通过sendFile同步数据给Follower；

副本延迟和下线处理

  1. 如果某个Follower副本与Leader之间的网络延迟较大，或者Follower处理能力有限、或下线，导致无法及时跟上Leader的写入速度，那么该副本可能会被从ISR中移除；
  2. 重启后会放弃HW以后的数据，但是Leader仍然存有数据，会持续进行备份；
  3. Leader宕机，一样重启后，重新从HW开始同步数据，原本高于HW的数据丢失，并且其他副本没有来得及同步的数据可能丢失；（开启
    ACK = 1
    可以有效减少数据丢失的可能）

副本的恢复

  1. OSR中的副本或上线后的宕机副本，会首先从磁盘恢复HW之前的数据，抛弃HW之后的数据，保证数据一致性，因为HW是消费者能看到的最大数据偏移
  2. 然后向Leader进行数据同步，追赶Leader；
  3. 当副本追赶上Leader的数据进度(同步到整个Partition的HW)，会被加入ISR候选，Controller会进行检测是否可以将副本重新加入ISR；
  4. 如果Leader仍然可用，那么就将ISR候选，加入ISR队列；并广播新的ISR向其他节点；

offset管理

offset的存储

  1. offset保存在 Kafka 一个内置的topic中：
    __consumer_offsets
    ；
  2. offset由
    Group Coordinator
    进行管理；

使用key-value方式存储：

  • key：
    group.id + topic + partition.id
  • value: 消费的offset位置

消费方式

kafka按照消费者组为单位进行消费； 消费者组启动时，通过配置，选择开始消费位置：

auto.offset.reset = earliest / latest / none
  • none：从保存的offset继续消费；如果没有offset(新组)，抛出异常；
  • latest：从保存的offset继续消费；如果没有offset(新组)，则只消费上线后的新数据；
  • earliest：从保存的offset继续消费；无提交的offset时(新组)，从头开始消费；

offset的提交方式

自动提交：

# 是否自动提交
enable.auto.commit = true
# 自动提交频率
auto.commit.interval.ms = 1000

手动提交：

  • 同步提交：commitSync，可以进行失败重试；
  • 异步提交：commitAsync，失败需要自行额外保证；