ZAB 协议与 Raft协议比较

柔光的暖阳◎ 2022-12-17 14:56 296阅读 0赞

我们不仅要在平时工作和学习中，认真、全面的学习理论，掌握概念的内涵，还要能“包容”和“发展”着理解技术。

随着分布式的发展，对应的算法也在不断的演进。这里是学习了极客时间的一个专栏中，从中总结的关于ZAB协议与Raft协议之间的一个比较笔记总结。

**ZAB** 是通过“**一切以领导者为准”的强领导者模型和严格按照顺序处理、提交提案，来实现操作的顺序性的。**主节点是基于 **TCP 协议来广播消息的，并保证了消息接收的顺序性**。出来的比较早。

**Raft**协议是**Raft协议就是一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致性。通过日志的连续性来保证消息或者说是数据的顺序性以及完整性。Raft协议中日志不仅是数据的载体，同时，日志的完整性还会影响领导者选举的结果（注：选举的因素不仅仅只有日志的完整性来保证，还有任期等其他因素）。**

Raft目前是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。在这里强调了是在工程上，因为在学术理论界，最耀眼的还是大名鼎鼎的Paxos。如果想深入了解可以阅读：[Raft 协议原理详解][Raft]

Raft是作为共识算法和 Multi-Paxos 算法提出的。当它被广泛接受和认可后，共识算法的内涵也就丰富和发展了，不仅能实现一系列值的共识，还能保证值的顺序性。同样，Multi-Paxos 算法不仅指代多次执行 Basic Paxos 的算法，还指代主备、强领导者模型的共识算法。

从上面我们可以看出Raft 算法和 ZAB 协议很类似，比如主备模式（也就是领导者、跟随者模型）、日志必须是连续的、以领导者的日志为准来实现日志一致等等。有点像“英雄所见略同”。

同时也在ZAB协议的基础上做了一些改进（Raft协议比ZAB协议出来的晚），比如 ZAB 协议要实现操作的顺序性，而 Raft 的设计目标，不仅仅是操作的顺序性，而是线性一致性，这两个目标，都决定了它们不能允许日志不连续，要按照顺序提交日志，那么，它们就要通过上面的方法实现日志的顺序性，并保证达成共识（也就是提交）后的日志不会再改变。

这里我们就ZAB 和 Raft 做个对比，来具体说说 ZAB 和 Raft 的异同。既然我们要做对比，那么首先要定义对比标准，我是这么考虑的：你应该有这样的体会，同一个功能，不同的同学实现的代码都会不一样（比如数据结构、代码逻辑），所以过于细节的比较，尤其是偏系统实现方面的，意义不大（比如跟随者是否转发写请求到领导者，不仅意义不大，而且这是 ZAB 和 Raft 都没有约定的，是集群系统需要考虑的）。

我们可以从核心原理上做对比：

**领导者选举：**

ZAB 采用的“**见贤思齐、相互推荐**”的快速领导者选举（Fast Leader Election），**节点间通过PK竞争**（资本是所持有的信息）看哪个节点更适合做Leader，一个节点PK后，会将选票信息广播出去，最终选举出了大多数节点中数据最完整的节点。

Raft 采用的是“**一张选票、先到先得**”的自定义算法（注：里面包含了一个**随机等待时间的概念**，来保证最多几次选举就能完整选举过程。），这里简单说一下就是一个节点发现leader挂了，就选举自己为leader，然后通知其他节点，其他节点把选票投给第一个通知它的节点。（注：这里其实也会涉及到PK，根据数据的完整性以及任期等信息，如果通知它的节点 没有当前节点的数据完整等那么 当前节点是不会将选票投给该节点，这一块概念很多，建议看之前上面的博客文章）

以上看来，Raft 的领导者选举，需要通讯的消息数更少，选举也更快。

**日志复制：**

Raft 和 ZAB 相同，都是以领导者的日志为准来实现日志一致，而且**日志必须是连续的，也必须按照顺序提交。**

ZAB通过TCP来保证操作的顺序性。

Raft协议通过Log Entry 加自己的校验来实现日志的连续性。建议看上面的博客文章

**读操作和一致性：**

ZAB 的设计目标是操作的顺序性，**在 ZooKeeper 中默认实现的是最终一致性，读操作可以在任何节点上执行**；（注：很多地方说ZK是CP这没有毛病，但是并不是指ZK中的读写时强一致性，是指在发生P的时候，ZK是C，或者看到这个很懵，看下上面的博客，以及仔细看下CAP理论的图，里面也清晰的标记着在没发生P的时候，AC是可以共存的）

而 Raft 的设计目标是强一致性（也就是线性一致性），所以 Raft 更灵活（可以自己配置），Raft 系统既可以提供强一致性，也可以提供最终一致性，但是一般为了保证性能，默认提供的也是最终一致性。

**写操作：**

Raft 和 ZAB 相同，写操作都必须在领导者节点上处理。

**成员变更：**

Raft 和 ZAB 都支持成员变更，其中 ZAB 以动态配置（dynamic configuration）的方式实现的。那么当你在节点变更时，不需要重启机器，集群是一直运行的，服务也不会中断。

**其他：**

相比 ZAB，Raft 的设计更为简洁，比如 Raft 没有引入类似 ZAB 的成员发现和数据同步阶段，而是当节点发起选举时，递增任期编号，在选举结束后，广播心跳，直接建立领导者关系，然后向各节点同步日志，来实现数据副本的一致性。

ZAB协议的数据同步的阶段，ZAB集群式无法对外提供服务。

其实，ZAB 的成员发现，可以和领导者选举合到一起，类似 Raft，在领导者选举结束后，直接建立领导者关系，而不是再引入一个新的阶段；数据同步阶段，是一个冗余的设计，可以去除的，因为 ZAB 不是必须要先实现数据副本的一致性，才可以处理写请求，而且这个设计是没有额外的意义和价值的。

还有，ZAB 和 ZooKeeper 强耦合，你无法在实际系统中独立使用；而 Raft 的实现（比如 Hashicorp Raft）是可以独立使用的，编程友好。

1024这一天，今天很忙，但是在晚上的时候，我写这下这篇质量不高的文章，主要是刚好对Raft协议以及ZAB协议的学习做一个消息的总结，也是给自己立下一个flag，让明年的自己能想起2020.10.24这一天，让自己一直记住下面这句话：

**天行健，君子以自强不息；地势坤，君子以厚德载物**