差不多的分布式一致性算法：Paxos、Raft、ZAB

前言

在分布式系统中，如何确保一致性始终是绕不开的话题。无论是对分布式事务的处理、数据副本之间的同步，还是集群节点状态的管理。为此，就诞生了很多分布式一致性算法和协议，比如Paxos算法、ZAB协议、Raft算法、以及当下比较火的区块链共识机制。

为什么这么多分布式一致性算法

为什么会有这么多的分布式一致性算法，我认为有两个原因：

1. 分布式一致性的应用场景多样，不同的场景对一致性的处理也就不一样。
2. 技术永远是与时俱进的，没有一成不变的方法，只要满足场景就是最合适的。

事实上，这些分布式一致性算法的最终目的都是一样的，只是处理方法不同。当理解了分布式一致性的核心思想时，其它的一致性算法也就不攻自破了。

分布式系统确保一致性的基础

在了解分布式一致性算法之前，需要有一个基本的认识。

在分布式系统中，各节点要实现一致性首先需要通信，而通信方式有两种：共享内存和消息传递。

举个例子：

作为一名Java开发人员，我们通常会使用Redis组件在分布式系统中实现数据共享，通过这种方式可以实现系统中的各节点访问数据时是一致的（Redis 单点）。这种场景下，Redis就属于分布式系统中的共享内存。

但是，作为一个组件，Redis需要保证高可用，于是就采取了一些措施，比如主从架构、哨兵模式、集群架构。无论哪种架构，都需要解决一个问题：集群之间的数据同步。这个场景下，Redis自身就是一个分布式系统，需要通过消息传递的方式实现数据同步，也就是一致性。

通用的分布式一致性算法：Paxos

Paxos 背景

Paxos算法是莱斯利·兰伯特（英语：Leslie Lamport，LaTeX中的“La”）于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。

基于消息传递通信方式构建的分布式组件，不可避免会发生以下错误：

• 某个进程可能被杀死或者重启。
• 消息可能会丢失、重复。

当发生这些问题时，各节点之间的数据如何保持一致就是一个问题。

为了解决一致性问题，Paxos算法应运而生。它的目标是：

确保一个分布式系统不论发生上述任何异常，都不会破坏一致性。

那么，Paxos 是如何确保的？

Paxos 确保一致性的方法

Paxos 对一致性的处理方法是：

当某个节点做任何操作时（例如写数据），需要其他节点投票通过才能生效。

Paxos 处理一致性的流程

为了直观的理解Paxos算法，这里通过一个典型的场景进行说明：

在一个分布式数据库系统中，不论各节点正常或异常，每个节点需要执行相同顺序的操作，最后才能得到一致的状态。

那么，Paxos是如何通过投票保证执行顺序是一致的？

在投票时需要两个信息（全局唯一编号、具体操作），具体过程如下：

1. 当某个节点进行某项操作时，向其他节点发送投票请求。
2. 提交投票请求时会将一个全局唯一、递增的编号(N)发送给其他节点。
3. 其他节点收到这个投票请求后，会和自己处理过的最大编号进行比较：
   • 如果小于编号(N)，那么将它处理过的最大编号响应给对方，意味着认可这个操作。
   • 如果大于编号(N)，则代表编号(N)被处理过，就不会对对方任何响应，意味着不认可这个操作。
4. 当投票发送者收到半数以上响应后，会再次发送一个确认请求。
5. 当其他节点在收到确认的请求后，如果对该编号的投票请求做出过响应，并且不小于处理过的最大编号，该节点就执行本次的操作并更新编号。

每个节点都可以发起投票请求

通过上述执行流程可以得知，Paxos 通过全局唯一编号确保执行顺序一致性。

而且，当出现错误异常时也不会破坏一致性：

Paxos 高度容错的机制

• 某个进程可能被杀死或者重启：
  • 当某个进程被杀死后，投票发送者如果没有收到半数以上响应，所有节点都不会执行本次的操作，系统的一致性就不会被破坏。
  • 当某个进程重启后，会收集半数以上正常运行节点的数据和状态信息，以便恢复和同步自己的数据，系统的一致性就不会被破坏。
• 消息可能会丢失、重复：
  • 如果在投票请求阶段没有收到半数以上响应，可能意味着消息的丢失，那么所有节点都不会执行本次的操作，系统的一致性就不会被破坏。
  • 由于编号是唯一的，各节点在接收到投票请求后，不会对之前重复的编号进行处理，系统的一致性就不会被破坏。

其他分布式一致性算法

相对于 Paxos 算法，ZAB和Raft理解起来就比较直观了，原因是两者有具体的场景。

ZAB 协议

ZAB 协议（ZooKeeper Atomic Broadcast）是 ZooKeeper 用来保证集群节点之间的数据同步。所以在理解 ZAB 协议前需要对 ZooKeeper 有所了解。

这里总结一下 ZAB 协议做的几件事：

1. 投票选举 ZooKeeper 集群的 Leader 节点（ZooKeeper 所有的写操作统一经过 Leader 节点）。
2. 通过投票广播的方式保证集群之间的数据一致。
3. 节点崩溃后进行崩溃恢复（涉及到 Leader 重新选举以及数据同步）。

当你把 Paxos 投票流程运用到这几个场景中，会发现处理过程基本一致。

Raft 算法

Raft官方将算法解决的场景分为以下几点：选举、日志复制、安全性。看上去和ZAB协议在场景上的表现上高度相似。

同样，当你把 Paxos 投票流程运用到这几个场景中，会发现处理过程基本一致。

如果想要更直观地理解 Raft 算法。可以移步 Raft 提供的易于理解的分布式一致性动画演示：

http://thesecretlivesofdata.com/raft/

总结

不论是哪种分布式一致性算法，目的都很明确。对于不同的场景，处理细节可能会有所不同。当理解分布式一致性的核心原理后，所有的算法看起来都是高度相似的。

我正在参与2024腾讯技术创作特训营最新征文，快来和我瓜分大奖！