关于kafka:Kafka核心技术概念与架构原理

简介

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分区调配策略的介绍。

简介

Kafka一些重要概念

Kafka原理

控制器选举及复原

分区leader的选举

更多福利