泛泛而谈：白话分布式一致性与共识算法

Posted 2022-12-11 dreamcode

说的简单明了他们说你是泛泛而谈，算法这东西是讲明白的吗？自己不动手光想听别人讲就能明白，还想深刻明白，天下哪有这种便宜事！好吧，我就泛泛而谈吧。

1. 分布式系统问题

多节点，提高了系统整体的负载能力；可以使用多个处理器，同步查询，提高查询性能；可以有更多节点复制数据，增强了失败情况下的恢复能力，提高了系统整体的可用性。但是，分布式处理增加了系统各个方面的复杂度，关键问题是解决如何通信问题。

（1）分布式系统的先天不足—CAP理论

2000年，Eric Brewer教授在ACM分布式计算年会上指出了著名的CAP理论：分布式系统不可能同时满足一致性(Consistency)，可用性(Availability)和分区容错性(Tolerance of network Partition) 这三个需求。

一致性 Consistency：系统在执行过某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。 等同于所有节点访问同一份最新的数据副本。这个和数据库ACID的一致性类似，但这里关注的是所有数据节点上的数据一致性和正确性，而数据库的ACID关注的是在一个事务内，对数据的一些约束。

可用性 Availability：每一个操作总是能够在一定的时间内返回结果，这里需要注意的是“一定时间内”和“返回结果”。一定时间指的是，在可以容忍的范围内返回结果，结果可以是成功或者失败。关注的是在某个结点的数据是否可用，可以认为某一个节点的系统是否可用，通信故障除外。

分区容错性 Partition Tolerance：是否可以对数据进行分区。存在网络分区的情况下，仍然可以接受请求。

（2）最终一致性、CAP理论、BASE原则

最终一致性就是等会儿就一致了，早晚会一致的。使用最终一致性的关键就是想方设法让用户“等会儿”。办法是让用户知道（对用户透明），这个方法有个学名叫“用户感知到的一致性”，意思就是让用户自己知道数据已经不一致了，你再忍会儿。

虽然分布式系统不符合ACID原则，但是我们符合NOACID原则。我们换个词，就叫BASE原则（基本可用性、软状态与最终一致性）。BASE的含义就是指：设计可以通过牺牲一定的数据一致性和容错性来换取高性能的保持甚至提高。其实所有的分布式系统都是牺牲C（一致性 Consistency ）来换取P（分区容错性 Partition Tolerance ），而不是牺牲A（可用性 Availability ）。可用性是所有分布式系统共同追求的特性。

二、共识算法

（1）拜占庭将军问题

就是说，皇帝发出的命令，各地区的将军能不能行动一致，怎么避免出现不一致，甚至出现叛徒。行动听指挥，Leader说了算。

避免分布式系统节点数据不一致，方法很简单，写操作由其中一个节点执行。这个Leader节点谁来做，这个Leader选举办法，就是一致性算法或共识算法。

（2）工作量证明机制(Proof of Work, POW)

手速快的，来做写节点Leader，谁手速快，比一比就知道了，就是POW算法。就是大家熟悉的挖矿，通过与或运算，计算出一个满足规则的随机数，即获得本次记账权，发出本轮需要记录的数据，全网其它节点验证后一起存储。
优点：完全去中心化，节点自由进出；缺点：目前Bitcoin已经吸引全球大部分的算力，其它再用Pow共识机制的区块链应用很难获得相同的算力来保障自身的安全；挖矿造成大量的资源浪费；共识达成的周期较长，不适合商业应用。

（3）股权证明机制(Proof of Stake, POS)

谁钱多谁来，根据每个节点所占代币的比例和时间，等比例的降低挖矿难度，从而加快找随机数的速度。
优点：在一定程度上缩短了共识达成的时间，对节点性能要求低，达成共识时间短，网络环境好的话可实现毫秒级；缺点：还是需要挖矿，本质上没有解决商业应用的痛点。

（4）授权股权证明机制(Delegate Proof of Stake, DPOS)

类似于公司董事会制度，选出一定数量的代表，来负责生产区块。这些代表是怎么被选出来的呢？是每一位持币人，根据手中的持有的代币投票选出来的。每个股东可以将其投票权授予一名代表，获票数最多的前100名代表按既定时间表轮流产生区块。

（5）实用拜占庭协议（PBFT）

PBFT是一种基于消息传递的一致性算法，算法经过三个阶段达成一致性，这些阶段可能因为失败而重复进行。该算法主要应用在IBM超级账本等联盟区块链或私有区块链场景中，容错率低、灵活性差，超过1/3的节点作恶就会导致系统崩溃，并且不可动态添加节点（这能算商用一致性算法吗？）。

假设节点总数为3f+1，f为拜占庭错误节点：

1）当节点发现leader作恶时，通过算法选举其他的replica为leader；

2）leader通过pre-prepare 消息把它选择的value广播给其他replica节点，其他replica节点如果接受则发送prepare，如果失败则不发送；

3）一旦2f个节点接受prepare消息，则节点发送commit消息；

4）当2f+1个节点接受commit消息后，代表该value值被确定。

三、Paxos算法

Paxos算法是莱斯利兰伯特于1990年提出的一种基于消息传递，具有高度容错特性的一致性算法。SunlightDB等区块链数据库使用这种算法，Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。

基于拜占庭将军问题解析：分为以下两种角色：proposer：提交者；acceptor： 决策者

1. 提交者1发起提议，派通信兵带信给3个决策者，内容为（编号1）
2. 3个决策者收到提交者1的提议，由于之前还没有保存任何编号，因此把（编号1）保存下来，避免遗忘；同时让通信兵带信回去，内容为（ok）
3. 提交者1收到至少2个决策者的回复，再次派通信兵带信给3个决策者，内容为（编号1，进攻时间1）
4. 3个决策者收到提交者1的时间，把（编号1，进攻时间1）保存下来，避免遗忘；同时让通信兵带信回去，内容为（Accepted）
5. 提交者1收到至少2个决策者的（Accepted）内容，确认进攻时间已经被大家接收；
6. 提交者2发起提议，派通信兵带信给3个决策者，内容为（编号2）
7. 3个决策者收到提交者2的提议，由于（编号2）比（编号1）大，因此把（编号2）保存下来，避免遗忘；又由于之前已经接受提交者1的提议，因此让通信兵带信回去，内容为（编号1，进攻时间1）
8. 提交者2收到至少2个决策者的回复，由于回复中带来了已接受的提交者1的提议内容，提交者2因此不再提出新的进攻时间，接受提交者1提出的时间

一个潜在的问题是 proposer 在此过程中出现故障，可以通过超时机制来解决。极为凑巧的情况下，每次新的一轮提案的 proposer 都恰好故障，系统则永远无法达成一致（概率很小）。Paxos 能保证在超过50%的正常节点存在时，系统能达成共识。