回想一下，我们搭建kafka集群是如何搭建？修改kafka得配置文件，多个Kafka服务注册到同一个zookeeper集群上的节点，会自动组成集群。
学习服务端原理，通常我们是去读服务端的那些抽象的代码，但是Kafka为了保证高吞吐，高性能，高可扩展的三高架构，很多具体设计都是相当复杂的。如果直接跳进去学习研究，估计我们很快就会晕头转向。那么有没有一些可见的东西让我们更具体的理解Kafka的Broker运行机制呢?
kafka依赖于zookeeper，Kafka会将每个服务的不同之处，也就是状态信息，保存到Zookeeper中。通过Zookeeper中的数据，指导每个Kafka进行与其他Kafka节点不同的业务逻辑。而将状态信息抽离后，剩下的数据，就可以直接存在Kafka本地，所有Kafka服务都以相同的逻辑运行。这种状态信息分离的设计，让Kafka有非常好的集群扩展性。
zk中存的kafka的数据：
既然kafka依赖这么多的存储数据,那么我们就从可见的存储数据的角度来理解分析一下Kafka的Broker运行机制。
1. kafka在zookeeper中整体的数据
Kafka将状态信息保存在Zookeeper中，这些状态信息记录了每个Kafka的Broker服务与另外的Broker服务有什么不同。通过这些差异化的功能，共同体现出集群化的业务能力。这些数据，需要在集群中各个Broker之间达成共识，因此，需要存储在一个所有集群都能共同访问的第三方存储中。
这些共识数据需要保持强一致性，这样才能保证各个Broker的分工是同步、清晰的。而基于CP实现的Zookeeper就是最好的选择。另外，Zookeeper的Watcher机制也可以很好的减少Broker读取Zookeeper的次数。
Kafka在Zookeeper上管理了哪些数据呢？这个问题可以先回顾一下Kafka的整体集群状态结构，然后再去Zookeeper上验证。
Kafka的整体集群结构如下图。其中红色字体标识出了重要的状态信息。
Kafka的集群中，最为主要的状态信息有两个：
一个是在多个Broker中，需要选举出一个Broker，担任Controller角色。由Controller角色来管理整个集群中的分区和副本状态。
另一个是在同一个Topic下的多个Partition中，需要选举出一个Leader角色。由Leader角色的Partition来负责与客户端进行数据交互。
这些状态信息都被Kafka集群注册到了Zookeeper中。Zookeeper数据整体如下图：
对于Kafka往Zookeeper上注册的这些节点，大部分都是比较简明的。
比如/brokers/ids下，会记录集群中的所有BrokerId，
/topics目录下，会记录当前Kafka的Topic相关的Partition分区等信息。
下面就从这些Zookeeper的基础数据开始，来逐步梳理Kafka的Broker端的重要流程
为了方便我们看数据，后续主要用Zookeeper客户端工具： prettyZoo。来明了的看kafka存在zk上的数据结构。
下载地址：https://github.com/vran-dev/PrettyZoo/releases文章来源：https://www.toymoban.com/news/detail-804090.html
2. Controller Broker选举机制
3. Leader Partition选举机制
4、Leader Partition自动平衡机制
5、Partition故障恢复机制
6、HW一致性保障-Epoch更新机制
内容更新中~文章来源地址https://www.toymoban.com/news/detail-804090.html
到了这里，关于kafka之集群工作机制理解的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
