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的处理流程：
- controller在zk的broker节点上注册了watch，一旦有broker宕机，对应的zk节点将被删除，controller获得回调通知（BrokerChangeListener），调用方法controller.onBrokerFailure.
- Controller获得宕机broker中作为leader的partition，置为OfflinePartition状态
- 选举宕机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
- 删除宕机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）流程
- 新增broker启动后会自动在zookeeper上注册临时节点
- controller监听到zk节点发生变化，获取到新增broker的信息。给所有的broker发送新的broker metadata信息
新增broker（宕机后重启）流程
- 前面两步和broker上无partition的流程一致
- 获得新增broker的所有partition，并判断是否要重新选举这些partition的leader，假设需要重新选举，把新的leaderAndIsr信息发送到各broker
创建topic——kafka源码探究之一
https://segmentfault.com/a/11...
消息生产与消息存储——kafka源码探究之三
https://segmentfault.com/a/11...