Kafka Raft探索

背景

ZooKeeper 充当 Kafka 的领导者，用于发现新broker、扩容、迁移等。

Kafka2.8 之后，移除了Zookeeper的依赖，该版本将依赖于 ZooKeeper 的控制器改造成了基于 Kafka Raft 的 Quorm 控制器。

在 KRaft 中，一部分 broker 被指定为控制器，它提供过去由 ZooKeeper 提供的共识服务。所有集群元数据都将存储在 Kafka 主题中并在内部进行管理。

为什么移除Zookeeper？

1. 元数据存取困难
   元数据的存取过于困难，每次重新选举的controller需要把整个集群的元数据重新restore，非常的耗时且影响集群的可用性。

2. 元数据更新网络开销大
   整个元数据的更新操作也是以全量推的方式进行，网络的开销也会非常大。

3. 强耦合违背软件设计原则
   Zookeeper对于运维来说，维护Zookeeper也需要一定的开销，并且kafka强耦合与zk也并不好，还得时刻担心zk的宕机问题，违背软件设计的高内聚，低耦合的原则。

4. 网络分区复杂度高
   Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长。

5. zk本身不适合做消息队列
   zookeeper不适合做消息队列，因为zookeeper有1M的消息大小限制 zookeeper的children太多会极大的影响性能znode太大也会影响性能 znode太大会导致重启zkserver耗时10-15分钟 zookeeper仅使用内存作为存储，所以不能存储太多东西。

6. 并发访问zk问题多
   最好单线程操作zk客户端，不要并发，临界、竞态问题太多。

为什么KRaft？

1. 更简单的部署和管理
   通过只安装和管理一个应用程序， Kafka 集群的运维复杂性直接减半；

2. 提高可扩展性
   KRaft 的恢复时间比 ZooKeeper 快一个数量级。这使我们能够有效地扩展到单个集群中的数百万个分区。ZooKeeper 的有效限制是数万；

3. 更有效的元数据传播
   基于日志、事件驱动的元数据传播可以提高 Kafka 的许多核心功能的性能。

Raft算法

分布式系统为了提高系统的可靠性，一般都会选择使用多副本的方式来进行实现，例如hdfs当中数据的多副本，kafka集群当中分区的多副本等，但是一旦有了多副本的话，那么久面临副本之间一致性的问题，而一致性算法就是用于解决分布式环境下多副本的数据一致性的问题。业界最著名的一致性算法就是大名鼎鼎的Paxos，但是Paxos比较晦涩难懂，不太容易理解，所以还有一种叫做Raft的算法，更加简单容易理解的实现了一致性算法。

Raft为了达到易懂易用的目标，主要做了两件事：

• 分解问题（decomposition），即将复杂的分布式共识问题拆分为领导选举（leader election）、日志复制（log replication）和安全性（safety）三个子问题，并分别解决；
• 压缩状态空间（state space reduction），相对于Paxos算法而言施加了更合理的限制，减少因为系统状态过多而产生的不确定性。

Raft算法的基础——复制状态机

在共识算法中，所有服务器节点都会包含一个有限状态自动机，名为复制状态机（replicated state machine）。每个节点都维护着一个复制日志（replicated logs）的队列，复制状态机会按序输入并执行该队列中的请求，执行状态转换并输出结果。可见，如果能保证各个节点中日志的一致性，那么所有节点状态机的状态转换和输出也就都一致。共识算法就是为了保障这种一致性的，下图示出简单的复制状态机及其相关架构。

1. 某个节点的共识模块（包含共识算法的实现）从客户端接收请求。
2. 该共识模块将请求写入自身的日志队列，并与其他节点的共识模块交流，保证每个节点日志都相同。
3. 复制状态机处理日志中的请求。
4. 将输出结果返回给客户端。

Raft协议当中的角色分布

Raft协议将分布式系统当中的角色分为Leader（领导者），Follower（跟从者）以及Candidate（候选者）：

• Leader：主节点的角色，主要是接收客户端请求，并向Follower同步日志，当日志同步到过半及以上节点之后，告诉follower进行提交日志。
• Follower：从节点的角色，接受并持久化Leader同步的日志，在Leader通知可以提交日志之后，进行提交保存的日志。
• Candidate&#x