共计 3313 个字符，预计需要花费 9 分钟才能阅读完成。
简介
Kafka 起初是由 LinkedIn 公司采⽤ Scala 语⾔开发的⼀个多分区、多正本且基于 ZooKeeper 协调的分布式 音讯零碎，现已募捐给 Apache 基⾦会。⽬前 Kafka 曾经定位为⼀个分布式流式解决平台，它以⾼吞吐、可长久化、可⽔平扩大、⽀持流数据处理等多种个性被⼴泛使⽤。
在 0.10 版本之前，Kafka 次要定位是分布式、⾼吞吐、低提早的音讯引擎，平时⼯作中常⽤的消息中间件还有很多，⽐如 RabbitMQ，RocketMQ 等。
从 0.10 版本开始，Kafka 提供了连接器（kafka connect）和流解决（kafka stream），定位也从音讯引擎变为流式解决平台。⽬前⽐较流⾏的另⼀个流式解决平台 Pulsar。Pulsar 与 Kafka 的对⽐也被⼤家津津有味，其⼤局部都是对⽐ Pulsar 和 Kafka 在性能、架构和个性⽅⾯的区别。
Kafka 一些重要概念
- Producer：音讯⽣产者，向 Kafka Broker 发消息的客户端。
- Consumer：音讯消费者，从 Kafka Broker 取音讯的客户端。
- Consumer Group：消费者组 (CG)，消费者组内每个消费者负责生产不同分区的数据，提⾼生产能 ⼒。⼀个分区只能由组内⼀个消费者生产，消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的⼀个订阅者。
- Broker：⼀台 Kafka 机器就是⼀个 Broker。⼀个集群由多个 Broker 组成。⼀个 Broker 能够包容多个 Topic。
- Topic：能够了解为⼀个队列，Topic 将音讯分类，⽣产者和消费者⾯向的是同⼀个 Topic。
- Partition：为了实现扩展性，提⾼并发能⼒，⼀个⾮常⼤的 Topic 能够散布到多个 Broker (即服务器) 上，⼀个 Topic 能够分为多个 Partition，每个 Partition 是⼀个有序的队列。
- Replica：正本，为实现备份的性能，保障集群中的某个节点发⽣故障时，该节点上的 Partition 数据不失落，且 Kafka 依然可能持续⼯作，Kafka 提供了正本机制，⼀个 Topic 的每个分区都有若⼲个正本，⼀个 Leader 和若⼲个 Follower。
- Leader：每个分区多个正本的“主”正本，⽣产者发送数据的对象，以及消费者生产数据的对象，都是 Leader。
- Follower：每个分区多个正本的“从”正本，实时从 Leader 中同步数据，放弃和 Leader 数据的同步。Leader 发⽣故障时，某个 Follower 还会成为新的 Leader。
- Offset：消费者生产的地位信息，监控数据生产到什么地位，当消费者挂掉再从新复原的时候，能够从生产地位持续生产。
- Zookeeper：Kafka 集群可能失常⼯作，须要依赖于 Zookeeper，Zookeeper 帮忙 Kafka 存储和 治理集群信息。
Kafka 原理
控制器选举及复原
控制器是 Kafka 的核⼼组件之⼀，它的次要作⽤是在 ZooKeeper 的帮忙下协调和治理整个 Kafka 集群。Kafka 利⽤ ZooKeeper 的领导者选举机制，每个 Broker 都会参加竞选主控制器，然而最终只会有⼀个 Broker 能够成为主控制器。
控制器有以下⼏个职责：
- 监听分区相干的变动，例如：运⾏ kafka-reassign-partitions.sh 脚本对已有主题分区的细粒度的调配性能
- 监听主题相干的变动
- 监听 broker 相干的变动
控制器选举：每个代理节点都会作为 ZooKeeper 的客户端，向 ZooKeeper 服务端尝试创立 /controller 长期节点，然而最终只有 1 个 Broker 能够胜利创立长期节点。因为 /controller 节点是长期节点，当主控制器呈现故障或者会话生效时，长期节点会被删除。此时所有的 Broker 都会从新竞选 Leader，也就是尝试创立 /controller 长期节点。
Kafka 控制器将 Broker 节点信息寄存在 ZooKeeper 的 /controller 节点上，每个 broker 都会在内存中保留以后控制器的 brokerid 值，这个值能够标识为 activeControllerId，每个 broker 还会对 /controller 节点增加监听器，以此来监听此节点的数据变动。
当 /controller 节点的数据发⽣变动时，每个 broker 都会更新⾃身内存中保留的 activeControllerId。如果 broker 在数据变更前是控制器，在数据变更后⾃身的 brokerid 值与新的 activeControllerId 值不⼀致，那 么就须要“退位”，敞开相应的资源。有可能控制器因为异样⽽下线，造成 /controller 这个长期节点被⾃动 删除；也有可能是其余起因将此节点删除了。
当 /controller 节点被删除时，每个 broker 都会进⾏选举。如果有非凡须要，则能够⼿动删除 /controller 节点来触发新⼀轮的选举，当然敞开控制器对应的 broker 以及手动向 /controller 节点写⼊新的 brokerid 所对应的数据同样能够触发新⼀轮的选举。
分区 leader 的选举
分区 leader 正本的选举由 Kafka Controller 负责具体实施。当创立分区（创立主题或减少分区都有创立分区的动作）或分区上线（⽐如分区中原先的 leader 正本下线，此时分区须要选举⼀个新的 leader 上线来 对外提供服务）的时候都须要执⾏ leader 的选举动作。
基本思路是依照 AR 汇合中正本的程序查找第⼀个存活的正本，并且这个正本在 ISR 汇合中。⼀个分区的 AR 汇合在调配的时候就被指定，并且只有不发⽣重调配的状况，汇合外部正本的程序是放弃不变的，⽽ 分区的 ISR 汇合中正本的程序可能会扭转。留神这⾥是依据 AR 的程序⽽不是 ISR 的程序进⾏选举的。举个 例⼦，集群中有 3 个节点:broker0、broker1、broker2，在某⼀时刻具备 3 个分区且正本因⼦为 3 的主题
quickstart 的具体信息如下：
此时敞开 broker0，那么对于分区 2 ⽽⾔，存活的 AR 就变为 [1,2]，同时 ISR 变为 [2,1]。此时查看主题 quickstart 的具体信息，分区 2 的 leader 就变为了 1 ⽽不是 2。
如果 ISR 汇合中没有可⽤的正本，那么此时还须要再查看⼀下所配置的 unclean.leader.election.enable 参 数（默认值为 false）。如果这个参数配置为 true，那么示意容许从⾮ ISR 列表中选举 leader，从 AR 列表 中找到第⼀个存活的正本即为 leader。
当分区进⾏重调配的时候也须要执⾏ leader 的选举动作。这个选举策略⽐较简略：从重调配的 AR 列表中 找到第⼀个存活的正本，且这个正本在⽬前的 ISR 列表中。当发⽣优先正本的选举时，间接将优先正本设置为 leader 即可，AR 汇合中的第⼀个正本即为优先正本。
还有⼀种状况就是当某节点被优雅地敞开（也就是执⾏ ControlledShutdown）时，位于这个节点上的 leader 正本都会下线，所以与此对应的分区须要执⾏ leader 的选举。这⾥的具体思路为：从 AR 列表中找 到第⼀个存活的正本，且这个正本在⽬前的 ISR 列表中，与此同时还要确保这个正本不处于正在被敞开的 节点上。
Kafka 的外围概念咱们就介绍到这里，下一篇文章，咱们将为大家带带来 Kafka 分区调配策略的介绍。
更多福利
云智慧已开源集轻量级、聚合型、智能运维为一体的综合运维治理平台 OMP（Operation Management Platform），具备 纳管、部署、监控、巡检、自愈、备份、复原 等性能，可为用户提供便捷的运维能力和业务管理，在进步运维人员等工作效率的同时，极大晋升了业务的连续性和安全性。点击下方地址链接，欢送大家给 OMP 点赞送 star，理解更多相干内容～
GitHub 地址：https://github.com/CloudWise-…
Gitee 地址：https://gitee.com/CloudWise/OMP
微信扫描辨认下方二维码，备注【OMP】退出 AIOps 社区运维治理平台 OMP 开发者交换群，与 OMP 我的项目 PMC 当面交换，和更多行业大佬一起交流学习～
