解析Kafka High Available 二

Broker Failover过程

一、Controller对Broker failure的处理过程

    1、假设只有一台broker宕机
    2、Controller在ZooKeeper的/brokers/ids节点上注册Watch。一旦有Broker宕机,其在ZooKeeper对应的Znode会自动被删除,ZooKeeper会fire Controller注册的Watch,Controller即可获取最新的幸存的Broker列表。
    3、Controller决定set_p,该集合包含了宕机的Broker上的所有Partition分区
        3.1、set_p包含了, 所有topic下面分布在该broker上的partition分区leader
    4、对set_p中的每一个Partition:

        4.1、从/brokers/topics/[topic]/partitions/[partition]/state读取某一个Partition的ISR(容灾备份分区列表)。
            a、在这里需要注意的一个问题的是:这里所指的该broker上的partition,代表的就是某一个topic的其中一个partition分区的leader
            b、至于已该broker上的replica(其他partition的备份)是不关心的.
    5、决定该Partition的新Leader。如果当前ISR中有至少一个Replica还幸存,则选择其中一个作为新Leader,新的ISR则包含当前ISR中所有幸存的Replica。否则选择该Partition中任意一个幸存的Replica作为新的Leader以及ISR(该场景下可能会有潜在的数据丢失)(ISR里面只有一个replica,是被选为leader,因为只有一个了)。如果该Partition的所有Replica都宕机了,则将新的Leader设置为-1(表示某个topic下面的某一个partition分区已经完全损坏,该分区不能在使用)。
    6、将新的Leader,ISR和新的leader_epoch及controller_epoch写入/brokers/topics/[topic]/partitions/[partition]/state。注意,该操作只有Controller版本在3.1至3.3的过程中无变化时才会执行,否则跳转到3.1。
    7、直接通过RPC(远程网络调用)向set_p相关的Broker发送LeaderAndISRRequest命令。Controller可以在一个RPC操作中发送多个命令从而提高效率。

二、创建/删除Topic

    1、Controller在ZooKeeper的/brokers/topics节点上注册Watch,一旦某个Topic被创建或删除,则Controller会通过Watch得到新创建/删除的Topic的Partition/Replica分配。
        1.1、这句话写的真的很绕,通俗的说,就是controller在topics节点上注册了一个哨兵,只要topics发生改变其发生改变的topic已经啊topic下面的partition和rpelica都会被controller知道.
    2、对于删除Topic操作,Topic工具会将该Topic名字存于/admin/delete_topics。
        2.1、若delete.topic.enable为true,则Controller注册在/admin/delete_topics上的Watch被fire,Controller通过回调向对应的Broker发送StopReplicaRequest(停止从;leader哪里进行主从同步),
        2.2、若为false则Controller不会在/admin/delete_topics上注册Watch,也就不会对该事件作出反应。
    3、对于创建Topic操作,Controller从/brokers/ids读取当前所有可用的Broker列表,对于set_p中的每一个Partition:(为什么是set_p?)
        3.1、分配给该Partition(分区)的所有Replica(备份)(称为AR)中任选一个可用的Broker作为新的Leader,并将AR(备份列表)设置为新的ISR
            (因为该Topic是新创建的,所以AR中所有的Replica都没有数据,可认为它们都是同步的,也即都在ISR中,任意一个Replica都可作为Leader)
    4、将新的Leader和ISR写入/brokers/topics/[topic]/partitions/[partition]
    5、直接通过RPC向相关的Broker发送LeaderAndISRRequest。
      

三、Broker响应请求流程

      四个角色
        1、acceptor 请求接受这 
                Acceptor的主要职责是监听并接受客户端(请求发起方,包括但不限于Producer,Consumer,Controller,Admin Tool)的连接请求,并建立和客户端的数据传输通道,然后为该客户端指定一个Processor,至此它对该客户端该次请求的任务就结束了,它可以去响应下一个客户端的连接请求了
        2、Processor 请求中转处理者                                    
            Processor主要负责从客户端读取数据并将响应返回给客户端,它本身并不处理具体的业务逻辑,并且其内部维护了一个队列来保存分配给它的所有SocketChannel。Processor的run方法会循环从队列中取出新的SocketChannel并将其SelectionKey.OP_READ注册到selector上,然后循环处理已就绪的读(请求)和写(响应)。Processor读取完数据后,将其封装成Request对象并将其交给RequestChannel。
        3、RequestChannel 中转站
            RequestChannel是Processor和KafkaRequestHandler交换数据的地方,它包含一个队列requestQueue用来存放Processor加入的Request,KafkaRequestHandler会从里面取出Request来处理;同时它还包含一个respondQueue,用来存放KafkaRequestHandler处理完Request后返还给客户端的Response。
        4、KafkaRequestHandler 业务处理器
            循环从RequestChannel中取Request并交给kafka.server.KafkaApis处理具体的业务逻辑。
    Processor会通过processNewResponses方法依次将requestChannel中responseQueue保存的Response取出,并将对应的SelectionKey.OP_WRITE事件注册到selector上。当selector的select方法返回时,对检测到的可写通道,调用write方法将Response返回给客户端
  

四、LeaderAndIsrRequest响应过程

    对于收到的LeaderAndIsrRequest,Broker主要通过ReplicaManager的becomeLeaderOrFollower处理,流程如下:
        1、校验求中的controllerEpoch是否小于当前最新的controllerEpoch,小于则表示该条请求已经过期(已经有新的controller被选出) return 错误 否则继续
        2、对于请求中partitionStateInfos中的每一个元素,即((topic, partitionId), partitionStateInfo):
        3、检查每日一个元素的partitionStateInfo中的leader时间戳,是否小于当前broker所有用的该partition的leader时间戳小,小于则已过期,需要吧错误代码存入Response中,并且continue检查下一个元素,否则继续
        4、检查该元素的partitionStatrInfo中的broker_id 是否包含本broker_id,若是不包含,则记录一个error或者wore,然后continue下一个元素 若是包含 ,则继续
            在一开始搭建HA的时候已经确定好了每一个topic的partition(分区)置于那一部分broker之中,也就是有一个Replica list,所以,要是该list中本就不包含本台broker的id则说明这个分区不应该出现在这个broker上
            同样的也会有一份replica list 来决定每一个partition的备份群归属地,所以需要进行校
        5、该partition及partitionStateInfo存入一个名为partitionState的HashMap中
        6、筛选出partitionState中Leader与当前Broker ID相等的所有记录存入partitionsTobeLeader中,其它记录存入partitionsToBeFollower中 区分主从
        7、若partitionsTobeLeader不为空,则对其执行makeLeaders方。
        8、若partitionsToBeFollower不为空,则对其执行makeFollowers方法。
        9、若highwatermak线程还未启动,则将其启动,并将hwThreadInitialized设为true。
        10、关闭所有Idle状态的Fetcher。
        11、LeaderAndIsrRequest处理过程如下图所示
            

五、Broker启动过程

      Broker启动后首先根据其ID在ZooKeeper的/brokers/idszonde下创建临时子节点(Ephemeral node),创建成功后Controller的ReplicaStateMachine注册其上的Broker Change Watch会被fire,从而通过回调KafkaController.onBrokerStartup方法完成以下步骤:
      向所有新启动的Broker发送UpdateMetadataRequest,其定义如下。
      将新启动的Broker上的所有Replica设置为OnlineReplica状态,同时这些Broker会为这些Partition启动high watermark线程。
      通过partitionStateMachine触发OnlinePartitionStateChange。
  

六、Controller Failover

      Controller也需要Failover。每个Broker都会在Controller Path (/controller)上注册一个Watch。当前Controller失败时,对应的Controller Path会自动消失(因为它是Ephemeral Node),此时该Watch被fire,所有“活”着的Broker都会去竞选成为新的Controller(创建新的Controller Path),但是只会有一个竞选成功(这点由ZooKeeper保证)。竞选成功者即为新的Leader,竞选失败者则重新在新的Controller Path上注册Watch。因为ZooKeeper的Watch是一次性的,被fire一次之后即失效,所以需要重新注册。
      Broker成功竞选为新Controller后会触发KafkaController.onControllerFailover方法,并在该方法中完成如下操作:
        1、读取并增加Controller Epoch。
        2、在ReassignedPartitions Patch(/admin/reassign_partitions)上注册Watch。
        3、在PreferredReplicaElection Path(/admin/preferred_replica_election)上注册Watch。
        4、通过partitionStateMachine在Broker Topics Patch(/brokers/topics)上注册Watch。
        5、若delete.topic.enable设置为true(默认值是false),则partitionStateMachine在Delete Topic Patch(/admin/delete_topics)上注册Watch。
        6、通过replicaStateMachine在Broker Ids Patch(/brokers/ids)上注册Watch。
        7、初始化ControllerContext对象,设置当前所有Topic,“活”着的Broker列表,所有Partition的Leader及ISR等。
        8、启动replicaStateMachine和partitionStateMachine。
        9、将brokerState状态设置为RunningAsController。
        10、将每个Partition的Leadership信息发送给所有“活”着的Broker。
        11、若auto.leader.rebalance.enable配置为true(默认值是true),则启动partition-rebalance线程。
          12、若delete.topic.enable设置为true且Delete Topic Patch(/admin/delete_topics)中有值,则删除相应的Topic。
  

七、Partition重新分配

      管理工具发出重新分配Partition请求后,会将相应信息写到/admin/reassign_partitions上,而该操作会触发ReassignedPartitionsIsrChangeListener,从而通过执行回调函数KafkaController.onPartitionReassignment来完成以下操作:
        1、将ZooKeeper中的AR(Current Assigned Replicas)更新为OAR(Original list of replicas for partition) + RAR(Reassigned replicas)。
        2、强制更新ZooKeeper中的leader epoch,向AR中的每个Replica发送LeaderAndIsrRequest。
        3、将RAR - OAR中的Replica设置为NewReplica状态。
        4、等待直到RAR中所有的Replica都与其Leader同步。
        5、将RAR中所有的Replica都设置为OnlineReplica状态。
        6、将Cache中的AR设置为RAR。
        7、若Leader不在RAR中,则从RAR中重新选举出一个新的Leader并发送LeaderAndIsrRequest。若新的Leader不是从RAR中选举而出,则还要增加ZooKeeper中的leader epoch。
        8、将OAR - RAR中的所有Replica设置为OfflineReplica状态,该过程包含两部分。第一,将ZooKeeper上ISR中的OAR - RAR移除并向Leader发送LeaderAndIsrRequest从而通知这些Replica已经从ISR中移除;第二,向OAR -                         RAR中的Replica发送StopReplicaRequest从而停止不再分配给该Partition的Replica。
        9、将OAR - RAR中的所有Replica设置为NonExistentReplica状态从而将其从磁盘上删除。
        10、将ZooKeeper中的AR设置为RAR。
        11、删除/admin/reassign_partition。
        12、注意:最后一步才将ZooKeeper中的AR更新,因为这是唯一一个持久存储AR的地方,如果Controller在这一步之前crash,新的Controller仍然能够继续完成该过程。

        

八、Follower从Leader Fetch数据

    Follower通过向Leader发送FetchRequest获取消息              
        每个Fetch请求都要指定最大等待时间和最小获取字节数,以及由TopicAndPartition和PartitionFetchInfo构成的Map。实际上,Follower从Leader数据和Consumer从Broker Fetch数据,都是通过FetchRequest请求完成,所以在FetchRequest结构中,其中一个字段是clientID,并且其默认值是ConsumerConfig.DefaultClientId
    Leader收到Fetch请求后,Kafka通过KafkaApis.handleFetchRequest响应该请求,响应过程如下
        1、replicaManager根据请求读出数据存入dataRead中。
        2、如果该请求来自Follower则更新其相应的LEO(log end offset)以及相应Partition的High Watermark
        3、根据dataRead算出可读消息长度(单位为字节)并存入bytesReadable中。
        4、满足下面4个条件中的1个,则立即将相应的数据返回
            4.1、Fetch请求不希望等待,即fetchRequest.macWait <= 0
            4.2、Fetch请求不要求一定能取到消息,即fetchRequest.numPartitions <= 0,也即requestInfo为空
            4.3、有足够的数据可供返回,即bytesReadable >= fetchRequest.minBytes
            4.4、读取数据时发生异常
        5、若不满足以上4个条件,FetchRequest将不会立即返回,并将该请求封装成DelayedFetch。检查该DeplayedFetch是否满足,若满足则返回请求,否则将该请求加入Watch列表
                  

这是我对篇博客的理解,大部分是一样的.但是我加了自己学习的批注(括号或者小点)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值