broker的高可用及高伸缩——kafka源码探究之二

高可用

高可用机制

Kafka在0.8之前的版本，并不提供高可用机制，一旦一个broker宕机，则宕机期间该broke上的全部partition均不可用。从0.8版本开始，kafka开始提供高可用机制。
Kafka的高可用是经过多副本机制保证的。每一个topic下的partition都有主分区以及多个follower（该值可在建立topic时设置，也可后续动态修改），但replica数量不能大于broker数量。好比有3个broker，建立topic的replica必须小于等于3.
kafka的多副本机制是partition级别的，每一个partition及其副本统称为replica，replica包括leader和follower，生产者和消费者都只和leader交互，其余副本只负责从leader处复制消息，leader宕机后由controller选举一个新的leader。（这一点和elasticsearch很类似）

broker宕机后controller处理流程

如下详细阐述某个broker宕机后kafka的处理流程：

1. controller在zk的broker节点上注册了watch，一旦有broker宕机，对应的zk节点将被删除，controller得到回调通知（BrokerChangeListener），调用方法controller.onBrokerFailure.
2. Controller得到宕机broker中做为leader的partition，置为OfflinePartition状态
3. 选举宕机broker中做为leader partition的新leader，PartitionStateMachine#electLeaderForPartition，默认取ISR列表中的第一个replica。选举出新的leader后，更新zk以及controller缓存，最后构造leaderAndIsrRequest，rpc调用其余broker发送变更leader和isr的变更通知。其中leader选举算法以下：判断当前partition的ISR列表是否为空，若是不为空，选举ISR列表第一位replica做为leader；若是为空，判断配置是否容许选举非ISR列表的replica，不容许则直接抛出异常；容许则判断存活broker中非ISR的replica是否为空，为空直接抛出异常，不为空选举存活broker中replica的第一位做为leader
4. 删除宕机broker中非laeder的partition，若是删除该replica后无leader，则把leader置为-1，更新zk，更新controller缓存，同时rpc通知其余broker

高伸缩

高伸缩机制

kafka的高伸缩指的是broker的高伸缩，broker的高伸缩由自己的无状态保证。kafka中的broker集群可任意添加，并在下一次建立topic时分配partition，也可经过kafka提供的脚本手动调整原有topic的分区状况，下降原有broker的负载。
新增长broker对生产者和消费者是无感知的，对现有topic的分区和分片也无影响，不会自动作partition的rebalance。只有新的topic加入时才会用到。若是须要手动rebalance，可使用kafka提供的脚本实现。命令以下：
./kafka-reassign-partitions.sh --zookeeper 192.168.2.231:2181 --topics-to-move-json-file topic.json --broker-list "0,1,2" --generate
./kafka-reassign-partitions.sh --zookeeper 192.168.2.231:2181 --topics-to-move-json-file topic.json --broker-list "0,1,2" --execute

新增broker（该broker上无partition）流程

1. 新增broker启动后会自动在zookeeper上注册临时节点
2. controller监听到zk节点发生变化，获取到新增broker的信息。给全部的broker发送新的broker metadata信息

新增broker（宕机后重启）流程

1. 前面两步和broker上无partition的流程一致
2. 得到新增broker的全部partition，并判断是否要从新选举这些partition的leader，假设须要从新选举，把新的leaderAndIsr信息发送到各broker

建立topic——kafka源码探究之一
https://segmentfault.com/a/11...

消息生产与消息存储——kafka源码探究之三
https://segmentfault.com/a/11...