Gakkiyomi 👋🏼

KIP-500 在Kafka2.8之前，Kafka一直使用Zookeeper1来存储和管理Partition3和Broker4的元数据。以及选举一个Broker作为Kafka控制器 Kafka与Zookeeper5 Kafka移除Zookeeper1的动机 提高元数据管理的鲁棒性和可扩展性 支持更多分区 减少部署和配置难度 架构 当前，一个 Kafka 集群包含多个 broker 节点和一个外部的 ZooKeeper 仲裁节点。我们在这个图中描绘了 4 个 broker 节点和 3 个 ZooKeeper 节点，这是一个小型集群的典型规模。Kafka控制器（用橙色表示）在选举后从 ZooKeeper 仲裁节点加载其状态。控制器向其他 broker 节点推送更新，例如 LeaderAndIsr 和 UpdateMetadata 消息。 请注意，这个图有些误导。除了控制器，其他 broker 也会与 ZooKeeper 通信。因此，实际上应该从每个 broker 到 ZK 画线。然而，画这么多线会使图表难以阅读。另一个问题是，这个图省略了外部命令行工具和实用程序可以在没有控制器参....

简介 Raft 算法实际上是 Multi-Paxos的一个变种，通过新增两个约束： 追加日志约束 ：Raft 中追加节点的日志必须是串行连续的，而 Multi-Paxos 中则可以并发追加日志（实际上 Multi-Paxos 的并发也只是针对日志追加，最后应用到内部 State Machine 的时候还是必须保证顺序）。 选主的限制：Raft 中只有那些拥有最新、最全日志的节点才能当选 Leader 节点，而 Multi-Paxos 由于允许并发写日志，因此无法确定一个拥有最新、最全日志的节点，因此可以选择任意一个节点作为 Leader，但是选主之后必须要把 Leader 节点的日志补全。 基于这两个限制，Raft 算法的实现比 Multi-Paxos 更加简单易懂，不过由于 Multi-Paxos 的并发度更高，因此从理论上来说 Multi-Paxos 的性能会更好一些，但是到现在为止业界也没有一份权威的测试报告来支撑这一观点。 对比一下 Multi-Paxos 和 Raft 下集群中可能存在的日志顺序： 可以看出，Raft 中永远满足这样一个约束：follower log 一.......