简介Kafka最初是LinkedIn使用Scala语言开发的基于ZooKeeper协同的多分区、多副本、分布式消息系统，现已捐赠给Apache基金会。目前，Kafka已经定位为分布式流处理平台。它以其高吞吐量、持久性、水平可伸缩性和对流数据处理的支持而被广泛使用。在0.10版本之前，Kafka主要定位为分布式、高吞吐、低延迟的消息引擎。日常工作中常用的消息中间件有很多，比如RabbitMQ、RocketMQ。从0.10版本开始，Kafka提供了连接器（kafkaconnect）和流处理（kafkastream），其定位也从消息引擎变成了流处理平台。Pulsar，另一个当前流行的流媒体平台。Pulsar和Kafka的对比也是大家津津乐道的，大部分都是对比Pulsar和Kafka在性能、架构和特性上的差异。KafkaProducer的一些重要概念：消息生产者，向KafkaBroker发送消息的客户端。Consumer：消息消费者，从KafkaBroker中获取消息的客户端。ConsumerGroup：ConsumerGroup（CG），消费组中的每个消费者负责消费不同分区的数据，提高消费能力。一个partition只能被group中的一个consumer消费，consumergroup之间互不影响。所有的消费者都属于一个消费者组，即一个消费者组是一个逻辑上的订阅者。Broker：Kafka机器就是Broker。一个集群由多个Broker组成。一个Broker可以容纳多个Topic。Topic：可以理解为队列。主题对消息进行分类。生产者和消费者面临着同一个话题。Partition：为了实现可扩展性和提高并发性，可以将一个非常大的Topic分布到多个Broker（服务器）上，一个Topic可以划分为多个Partition。每个分区都是一个有序队列。Replica：为了实现备份功能，保证当集群中某个节点发生故障时，该节点上的Partition数据不会丢失，Kafka仍然可以继续工作。Kafka提供了副本机制。每个Topic每个分区都有几个副本，一个Leader和几个Follower。Leader：每个分区的多个副本的“主”副本，生产者发送数据的对象，消费者消费数据的对象都是领导者。Follower：每个分区的多个副本的“从”副本，实时从Leader同步数据，与Leader保持数据同步。当Leader失败时，一个Follower将成为新的Leader。Offset：consumer消费的位置信息，监听数据消费到哪里，当consumer挂掉再恢复时，可以从消费位置继续消费。Zookeeper：Kafka集群能够正常工作，需要依赖Zookeeper，Zookeeper帮助Kafka存储和管理集群信息。Kafka原理Controller选举与回收Controller是Kafka的核心组件之一，其主要功能是借助ZooKeeper协调和管理整个Kafka集群。Kafka使用ZooKeeper的leader选举机制。每个Broker都会参与主控制器的选举，但最终只有一个Broker可以成为主控制器。controller有以下职责：监控partition相关的变化，例如：运行kafka-reassign-partitions.sh脚本对现有的topic分区进行细粒度分配监控topic相关的变化监控broker相关的变化controller选举：每个proxynode会作为ZooKeeper客户端，尝试创建一个/controller临时节点到ZooKeeper服务器，但最终只有一个Broker能够成功创建临时节点。因为/controller节点是一个临时节点，当主controller失效或者session失效时，临时节点会被删除。这时候所有的Brokers都会重新选举Leader，即尝试创建/controller临时节点。Kafka控制器将Broker节点信息存放在ZooKeeper的/controller节点上。每个broker都会在内存中保存当前controller的brokerid值。该值可以标识为activeControllerId。每个broker也会在/controller节点上添加一个监听器，以监听这个节点的数据变化。当/controller节点的数据发生变化时，每个broker都会更新自己内存中保存的activeControllerId。如果broker在数据变化前是controller，而自身的brokerid值与数据变化后新的activeControllerId值不一致，那么就需要“退位”，关闭相应的资源。有可能controller异常下线，导致临时节点/controller被自动删除；它也可能因其他原因被删除。当/controller节点被删除时，每个broker都会被选举出来。如果有特殊需要，可以手动删除/controller节点，触发新一轮选举。当然关闭controller对应的broker，手动将新的brokerid对应的数据写入/controller节点也可以触发新一轮的选举。选举。partitionleader的选举partitionleader副本的选举是由KafkaController实现的。当创建分区（创建主题或添加分区有创建分区的动作）或上线时（例如分区中原来的leader副本下线，此时分区需要选举新的leader来上线对外提供服务）需要进行leader选举动作。基本思路是按照AR集合中replicas的顺序，找到第一个存活的replica，这个replica就在ISR集合中。分区的AR集在分配时就指定了，只要不发生重新分配，集合内副本的顺序保持不变，而分区的ISR集中副本的顺序可能会发生变化。注意，选举是按照AR的顺序，而不是ISR的顺序。例如集群中有3个节点：broker0、broker1、broker2。某时刻topicquickstart有3个partition，replicationfactor为3，具体信息如下：此时关闭broker0，那么对于partition2，也就是说存活的AR变成了[1,2]，并且ISR变为[2,1]。此时查看topicquickstart的具体信息，partition2的leader由2变为1，如果ISR集中没有replicas可用，需要查看配置的unclean.leader.election.enable参数（默认值为false）。如果该参数配置为true，则表示允许从非ISR列表中选举leader，从AR列表中找到的第一个存活副本为leader。当分区重新分配时，也需要进行leader选举动作。这个选举策略比较简单：从重新分配的AR列表中找到第一个存活的副本，这个副本在当前的ISR列表中。当发生优先级副本选举时，直接将优先级副本设置为leader即可，AR集中第一个副本为优先级副本。另一种情况是当一个节点被优雅关闭（即执行ControlledShutdown）时，这个节点上的leader副本会下线，所以对应的partition需要进行leader选举。这里的具体思路是：从AR列表中找到第一个存活的副本，并且这个副本在当前的ISR列表中，同时保证这个副本不在被关闭的节点上。到这里我们就介绍了Kafka的核心概念。在下一篇文章中，我们将介绍Kafka的分区分配策略。写在最后近年来，在AIOps领域高速发展的背景下，各行业对IT工具、平台能力、解决方案、AI场景和可用数据集的迫切需求呈爆发式增长。基于此，云智于2021年8月发布了AIOps社区，旨在竖起开源大旗，为各行业的客户、用户、研究人员和开发者打造一个活跃的用户和开发者社区，共同贡献和解决行业问题。问题，促进该领域的技术发展。社区先后开源了数据可视化与编排平台——FlyFish、运维管理平台OMP、云服务管理平台——Moore平台、Hours算法等产品。视觉编排平台-FlyFish：项目介绍：https://www.cloudwise.ai/flyF...Github地址：https://github.com/CloudWise-...Gitee地址：https://gitee.com/CloudWise/f...行业案例：https://www.bilibili.com/vide...部分大屏案例：可添加小助手（xiaoyuerwie）注：飞鱼。加入开发者交流群，与行业大咖1V1交流！您还可以通过小助手获取云智慧AIOps信息，了解飞鱼的最新进展！
