articleList

20-Kafka数据可靠性保证原理之副本机制Replica介绍

2025/03/13 posted in  Kafka
Tags: 

  • 背景

    • Kafka之间副本数据同步是怎样的?一致性怎么保证,数据怎样保证不丢失呢
  • kafka的副本(replica)

    • topic可以设置有N个副本, 副本数最好要小于broker的数量
    • 每个分区有1个leader和0到多个follower,我们把多个replica分为Learder replica和follower replica
      image-20210427205840695
  • 生产者发送数据流程

    • 保证producer 发送到指定的 topic, topic 的每个 partition 收到producer 发送的数据后
    • 需要向 producer 发送 ack 确认收到,如果producer 收到 ack, 就会进行下一轮的发送否则重新发送数据
  • 副本数据同步机制

    • 当producer在向partition中写数据时,根据ack机制,默认ack=1,只会向leader中写入数据
    • 然后leader中的数据会复制到其他的replica中,follower会周期性的从leader中pull数据
    • 对于数据的读写操作都在leader replica中,follower副本只是当leader副本挂了后才重新选取leader,follower并不向外提供服务,假如还没同步完成,leader副本就宕机了,怎么办?
  • 问题点:Partition什么时间发送ack确认机制(要追求高吞吐量,那么就要放弃可靠性)

    • 当producer向leader发送数据时,可以通过request.required.acks参数来设置数据可靠性的级别
    • 副本数据同步策略 , ack有3个可选值,分别是0, 1,all。
      • ack=0
        • producer发送一次就不再发送了,不管是否发送成功
        • 发送出去的消息还在半路,或者还没写入磁盘, Partition Leader所在Broker就直接挂了,客户端认为消息发送成功了,此时就会导致这条消息就丢失
      • ack=1(默认)
        • 只要Partition Leader接收到消息而且写入【本地磁盘】,就认为成功了,不管他其他的Follower有没有同步过去这条消息了
        • 问题:万一Partition Leader刚刚接收到消息,Follower还没来得及同步过去,结果Leader所在的broker宕机了
      • ack= all(即-1)
        • producer只有收到分区内所有副本的成功写入全部落盘的通知才认为推送消息成功
        • 备注:leader会维持一个与其保持同步的replica集合,该集合就是ISR,leader副本也在isr里面
        • 问题一:如果在follower同步完成后,broker发送ack之前,leader发生故障,那么会造成数据重复
          • 数据发送到leader后 ,部分ISR的副本同步,leader此时挂掉。比如follower1和follower2都有可能变成新的leader, producer端会得到返回异常,producer端会重新发送数据,数据可能会重复
        • 问题二:acks=all 就可以代表数据一定不会丢失了吗
          • Partition只有一个副本,也就是一个Leader,任何Follower都没有
          • 接收完消息后宕机,也会导致数据丢失,acks=all,必须跟ISR列表里至少有2个以上的副本配合使用
          • 在设置request.required.acks=-1的同时,也要min.insync.replicas这个参数设定 ISR中的最小副本数是多少,默认值为1,改为 >=2,如果ISR中的副本数少于min.insync.replicas配置的数量时,客户端会返回异常