摘要：高可用高可用机制在以前的版本，并不提供高可用机制，一旦一个宕机，则宕机期间该上的所有均不可用。的高可用是通过多副本机制保证的。选举出新的后，更新以及缓存，最后构造，调用其他发送变动和的变动通知。
高可用 高可用机制
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宕机后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启动后会自动在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...
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/33927.html
摘要：最好禁用，统一创建。随机选取一个步长，该作为与的间隔。一旦该目录子节点数发生变化会调用相应监听器的处理方法。最后设置副本对象状态为。 kafka是一款优秀的分布式消息队列，以吞吐量大，性能优秀著名。 一.相关的名词解释 broker：存储消息的物理实体，无状态，可多个扩展部署Topic：一类消息的集合Partition：一类消息的某个消息分区，一个topic有多个partition，可...
摘要：消息存储结构每个有多个，单个内消息有序。发送消息时，通过轮询或者随机选取的方式，决定消息被发送到哪一个。消息如何不丢消息到达后，先将该消息落盘。消息发送流程图如下创建源码探究之一的高可用及高伸缩源码探究之二 消息存储结构 kafka每个topic有多个partition，单个partition内消息有序。Partition在物理存储上由多个segment组成，每个segment内包含两...
摘要：能不能支持数据丢失啊可以的，参考我们之前说的那个数据零丢失方案其实一个肯定是很复杂的，其实这是个开放题，就是看看你有没有从架构角度整体构思和设计的思维以及能力。其实回答这类问题，说白了，起码不求你看过那技术的源码，起码你大概知道那个技术的基本原理，核心组成部分，基本架构构成，然后参照一些开源的技术把一个系统设计出来的思路说一下就好 比如说这个消息队列系统，我们来从以下几个角度来考虑一下 （1...
摘要：实际使用的是后两者持久化分为和。技术内幕技术内幕豆瓣通过前面这本书我们已经知道怎么用比较好了，现在我们来看看的实现原理。亮点采用单进程多线程模式。 后端好书阅读与推荐系列文章：后端好书阅读与推荐后端好书阅读与推荐（续）后端好书阅读与推荐（续二）后端好书阅读与推荐（续三）后端好书阅读与推荐（续四）后端好书阅读与推荐（续五） Redis设计与实现 Redis设计与实现 (豆瓣): http...
摘要：实际使用的是后两者持久化分为和。技术内幕技术内幕豆瓣通过前面这本书我们已经知道怎么用比较好了，现在我们来看看的实现原理。亮点采用单进程多线程模式。 后端好书阅读与推荐系列文章：后端好书阅读与推荐后端好书阅读与推荐（续）后端好书阅读与推荐（续二）后端好书阅读与推荐（续三）后端好书阅读与推荐（续四）后端好书阅读与推荐（续五） Redis设计与实现 Redis设计与实现 (豆瓣): http...
阅读 2394·2021-11-25 09:43
阅读 2501·2021-11-04 16:09
阅读 1468·2021-10-12 10:13
阅读 789·2021-09-29 09:35
阅读 758·2021-08-03 14:03
阅读 1585·2019-08-30 15:55
阅读 2862·2019-08-28 18:14
阅读 3355·2019-08-26 13:43
