kafka zookeeper

kafka zookeeper 中的leader和follower

zookeeper：leader 负责数据的读写，而follower只负责数据的读
kafka 不同，只有leader 负责读写，follower只负责备份。kafka在引入Replication之后，同一个Partition可能会有多个Replica，而这时需要在这些Replication之间选出一个Leader，Producer和Consumer只与这个Leader交互，其它Replica作为Follower从Leader中复制数据

Kafka的Leader是什么

首先Kafka会将接收到的消息分区（partition），每个主题（topic）的消息有不同的分区。这样一方面消息的存储就不会受到单一服务器存储空间大小的限制，另一方面消息的处理也可以在多个服务器上并行。
  其次为了保证高可用，每个分区都会有一定数量的副本（replica）。这样如果有部分服务器不可用，副本所在的服务器就会接替上来，保证应用的持续性。
  
kafka的选举：kafka分区的leader是由Controller指定的，而Controller是由zookeeper选举产生的，选举的方式是抢占模式，实现方式就是每个broker启动后，都会尝试在zookeeper中创建 同一个临时节点:/controller ， 并把自身的信息写入到这个节点中，谁抢到这个临时节点，谁就是leader，没抢到的节点就一直watch这个临时节点。
负责管理集群 broker 的上下线，所有 topic 的分区副本分配和 leader 选举等工作。
抢占式的方法要求是一个可以保证数据一致性的分布式存储，可以是zookeeper，redis，MySQL，HDFS

rockerMQ/Dledger，采用了Raft一致性算法投票选举

https://www.cnblogs.com/aspirant/p/9179045.html

左侧，每个临时节点对应一个在线的broker，节点名称就是brokerID，节点内保存了broker的地址，版本号，启动时间等；
右侧，每个分区节点下是一个state的临时节点，节点保存着分区当前的leader和所有的ISR的brokerID，是由当前的leader broker创建的，如果分区的主节点宕机了，该节点就消失了，直到新的leader选举出来，再次创建state。

kafka的客户端找到主题（队列）对应的broker：根据主题和队列，在右边的树种找到state，再去左侧树中找到brokerID对应的临时节点，就可以得到broker真正的地址了。

kafka在每个broker中都维护了和zookeeper中一样的元数据缓存，客户端连接时，先读取broker中的数据，而如果数据修改了，zookeeper中的watcher机制，会让kafka感知到zookeeper中的元数据变化了，及时更新broker中的缓存

Kafka 主要使用 ZooKeeper 来保存它的元数据、监控 Broker 和分区的存活状态，并利用ZooKeeper 来进行选举。

Kafka 在 ZooKeeper 中保存的元数据，主要就是Broker 的列表和主题分区信息两棵树。这份元数据同时也被缓存到每一个 Broker 中。客户端并不直接和 ZooKeeper 来通信，而是在需要的时候，通过 RPC 请求去 Broker 上拉取它关心的主题的元数据，然后保存到客户端的元数据缓存中，以便支撑客户端生产和消费。

Kafka（四）Kafka在zookeeper中的存储
https://www.cnblogs.com/frankdeng/p/9310713.html