本文主要是介绍kafka之协调服务，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
kafka中是使用zookeeper来构建集群的。
zookeeper相信大家都了解过，如果之前没接触过zookeeper的同学，可以参考学习下zookeeper的相关内容。知道zookeeper最核心的功能就是提供了一个分布式的存储系统，数据存储方式类似UNIX系统的文件树形结构。zookeeper保证了数据一致性。
学习zookeeper，我觉得zookeeper中最主要的是抓住两个特性：临时节点和watcher机制。
什么是临时节点？
在zookeeper文件树形存储结构中，每个节点被称为ZNode。zookeeper提供了一种特殊的ZNode类型，即为临时节点。临时节点有一个特性，如果创建临时节点的客户端与zookeeper集群失去了链接，那么这个临时节点也会消失。客户端和集群之前的链接也是通过心跳来维持的。
什么是Watcher机制？
一旦Znode或者它的子节点状态发生了变化，订阅的客户端就会立即收到通知。
kafka中有关zk的，是有个很大的版本差异，0.8.x版本之前，zk中是有存放消费者端消费位置等信息的，后面kafka的团队将这块的内容去zk化了。目前的版本中zk中只保存着kafka的两块信息，
左侧的树保存的是kafka的broker信息，红色的0，1代表的就是临时节点，每当有broker节点加入集群提供服务了，都会创建一个对应的临时节点，节点的名称默认就是BrokerID，节点内容包括了Broker的地址、版本号、启动时间等等一些Broker的基本信息。
右侧的树保存的就是主题和分区的信息，每个主题下都有一个固定的partitions节点，partitions节点下挂载着所有的分区0，1，...等多个分区，每个分区下都会有一个名为state的临时节点。这个临时节点保存着这个分区的leader和所有ISR的BrokerID信息。这个临时节点是由leader broker创建的，一旦leader broker宕机了，这些临时节点也会消失，直到下一个leader选举出来，由该leader来再次创建state临时节点。
有了上面的知识，我们就可以回答经常问的面试题，kafka客户端是如何找到对应的broker的？
客户端首先从有右侧的树开始查找对应的主题，对应的分区以及对应的state临时节点，临时节点中记录着leader的信息，拿到brokerid后再去左侧的树中查找。
当然客户端并不是每次都去zk上找对应的数据，kafka在每个broker中都维护了一份和zk中一样的元数据缓存在broker中，并不是每次客户端都去zk上请求数据，由于zk提供了watch的机制，所以当zk中的数据变化了，自然能够及时更新broker中的元数据信息。
这篇关于kafka之协调服务的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
