美文网首页
深入了解Kafka【三】数据可靠性分析

深入了解Kafka【三】数据可靠性分析

作者: ClawHub的技术分享 | 来源:发表于2019-12-08 21:54 被阅读0次

    1、多副本数据同步策略

    为了保障Prosucer发送的消息能可靠的发送到指定的Topic,Topic的每个Partition收到消息后,要向Producer发送ACK,如果Produser收到ACK,就会进行下一轮发送,否则重试。

    1.1、多副本概述

    为了提高消息的可靠性,Kafka每个Topic的partition都有N个副本(replica)。这N个副本中,其中一个replica是Leader,其他都是Follower。
    Leader负责处理Partition的所有请求,Follower负责同步Leader的数据。
    下图展示了Kafka集群中的4个Broker,Topic有3个Partition。

    1.2、同步副本队列ISR

    Partition什么时候才会发送ACK呢?
    要确保全部的Follower与Leader同步完成之后,Leader才能发送ACK,这样才能保证Leader挂掉之后,在所有Follower中能选出新的Leader。
    但是万一有一个Follower因为故障,迟迟不能和Leader同步,Leader就得等着它完成同步之后才能发送ACK,怎么决解呢?
    这就引出了ISR(in-sync replica set)。
    ISR在Leader中维护,也叫同步副本队列,就是leader + 与leader保持同步的followers的集合。
    当ISR中的Follower完成数据的同步之后,Leader就会给Producer发送ACK,如果Follower未在规定的时间同步数据,则将其踢出ISR。当Leader挂掉的时候,在ISR中选举出一个新的Leader。

    1.3、Follower与Leader之间数据复制原理

    在学习复制原理之前,先看两个概念:HW(HighWatermark)和LEO(LogEndOffset):

    • LEO指的是每个副本最后一个offset。
    • HW指的是所有副本中最小的LEO,Consumer能看到的partition的最后位置,即HW之前的数据才对Consumer可见。

    如图:


    Leader与Follower中,都会维护各自的HW,对于新消息的写入,Consumer并不能立即被消费,需要等待ISR中的Followers从Leader中复制完成。
    下图说明了新消息写入Partition后的数据复制过程:


    由图可知,Kafka的复制既不是同步也不是异步,其在可靠性和吞吐量上有很好的平衡。

    3、ACK应答机制与Exaclty Once语义

    当Producer向Leader发送数据的时候,可以通过Kafka提供的三种ACK应答机制,对数据的可靠性与延迟的要求做平衡。
    通过配置request.required.acks实现。

    3.1、0

    Producer不等待Broker的ACK,这能保证最低的延迟,但是当Broker故障时,数据可能丢失,即可靠性最低。
    体现了At Most Once语义,最多一次,数据只会发送一次,不保证数据会丢失。

    3.2、1

    Producer等待Broker中partition的Leader落盘成功后返回ACK。如果在Follower同步结束之前Leader故障,数据会丢失。

    3.3、-1

    Producer等待Partition的Leader和Follower全部落盘成功后返回ACK。如果在数据同步完成后,发送ACK之前Leader故障,Producer会重新发送消息,造成数据重复。
    这体现了At Least Once语义,至少一次,可以保证数据不会丢失,但是不保证数据重复。

    3.4、Exactly Once恰好一次

    At Least Once + 幂等性 = Exactly Once。
    Kafka中幂等性是通过Broker初始化时分配的PID来保证。发往同一Partition的消息会附带Sequence Number(SN),而Broker会对(PID,Partition,SN)做缓存,当相同主键的消息提交时,Broker只会持久化一条。
    但是PID重启后就会变化,不同的Partition也具有不同的主键,所以幂等性无法保证跨分区会话的Exactly Once。

    4、副本故障处理

    4.1、Follower故障

    Follower故障后会被临时踢出ISR,当Follower恢复后,Follower会读取本地磁盘记录的上次的HW,并将log文件高于HW的部分截取掉,从HW开始向Leader同步。等该Follower的LEO大于等于该partition的HW,即Follower追上Leader之后,就会被重新加入ISR。

    4.2、Leader故障

    Leader发生故障,会从ISR中选举出一个新的Leader,其余的Follower会先将各自的log文件高于各自HW的部分截取掉,之后从新的Leader同步数据。

    5、Leader选举

    kafka会在Zookeeper中为每个partition动态的维护着ISR,当Leader挂掉后,会从ISR中顺序选择一个Follower作为主。
    如果碰巧ISR中Follower全部挂掉,那么有两种选择:

    • 等待ISR中任意Follower恢复,选定其为Leader。
    • 选择第一个恢复的Follower作为Leader,这个Follower不一定在ISR中。

    怎么选择就要在可用性与一致性之间做权衡了。

    相关文章

      网友评论

          本文标题:深入了解Kafka【三】数据可靠性分析

          本文链接:https://www.haomeiwen.com/subject/kedvgctx.html