分布式系统一致性　　

一致性即是对于系统中的多个服务节点，在约定的协议下，执行相同的操作并保持状态的一致，简单来说就是多个节点持有相同的数据，如果数据要改变就应该每一个节点都做相同的改变。如果分布式系统能实现“一致”，对外就可以呈现为一个功能正常的，且性能和稳定性都要好很多的“虚处理节点”。
理想的分布式系统一致性应该满足：可终止性（Termination）、共识性（Consensus）、合法性（Validity）。

一致性难题

但是在实际的计算机集群中，可能会存在以下问题:

1. 节点之间的网络通讯是不可靠的，包括数据丢失、延迟、重复、损坏
2. 节点处理事务的能力不同，网络节点数据的吞吐量有差异
3. 节点可能死记，可能会有作恶节点出现
4. 当异步处理能力达到高度一致时，系统的可扩展性就会变差, 即容不下新节点的加入

弱一致性

可想而知，绝对理想的强一致性（Strong Consistency）代价很大。除非不发生任何故障，所有节点之间的通信无需任何时间，这个时候其实就等价于一台机器了。实际上，越强的一致性要求往往意味着越弱的性能
强一致的系统往往比较难实现。很多时候，人们发现实际需求并没有那么强，可以适当放宽一致性要求，降低系统实现的难度。例如在一定约束下实现所谓最终一致性（Eventual Consistency），即总会存在一个时刻（而不是立刻），系统达到一致的状态，这一类弱化的一致性，被笼统称为弱一致性（Weak Consistency）

一致性级别

• 强一致性 , 这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大　　
• 弱一致性 , 这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不久承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态　　
• 最终一致性 , 最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型

共识算法

实际上，要保障系统满足不同程度的一致性，往往需要通过共识算法来达成。共识算法解决的是对某个提案（Proposal），大家达成一致意见的过程。提案的含义在分布式系统中十分宽泛，如多个事件发生的顺序、某个键对应的值、谁是领导……等等，可以认为任何需要达成一致的信息都是一个提案。
“完美”的系统并不存在，响应请求往往存在时延、网络会发生中断、节点会发生故障、甚至存在恶意节点故意要破坏系统。一般地，把故障（不响应）的情况称为 “非拜占庭错误”，恶意响应的情况称为“拜占庭错误”。
针对非拜占庭错误的情况，一般包括 Paxos、Raft、zab 及其变种。对于要能容忍拜占庭错误的情况，一般包括 PBFT、PoW、Pos 算法等。

共识界限

一般情况下，分布式系统的共识问题无解。当节点之间的通信网络自身不可靠情况下，很显然，无法确保实现共识。但好在，一个设计得当的网络可以在大概率上实现可靠的通信。然而，即便在网络通信可靠情况下，一个可扩展的分布式系统的共识问题的下限是无解。这个结论，被称为 FLP 不可能性原理。FLP 不可能原理实际上告诉人们，不要浪费时间去为异步分布式系统设计在任意场景下都能实现共识的算法。

FLP 不可能性原理：在网络可靠，存在节点失效（即便只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确定性算法。

在付出一些代价的情况下，可以设计出一个大致可用的共识算法，这就是 CAP 理论。

CAP 理论：分布式计算系统不可能同时确保 一致性（Consistency）、可用性（Availablity）和 分区容忍性（Partition），设计中往往需要弱化对某个特性的保证。

一致性（Consistency）：任何操作应该都是原子的，发生在后面的事件能看到前面事件发生导致的结果，注意这里指的是强性；
可用性（Availablity）：在有限时间内，任何非失败节点都能应求；
分区容忍性（Partition）：网络可能发生分区，即节点之间的通信不可保障。

BASE 理论

BASE 是Basically Available（基本可用）、Soft state（软状态） 和Eventually consistent（最终一致性）三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于 CAP 定理逐步演化而来的。BASE 理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

1. 基本可用
   基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性 ---- 注意，这绝不等价于系统不可用。比如：　　
2. 软状态
   软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
3. 最终一致性
   最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

去中心化

在软件世界里，所谓的“去中心化”，实际上是可以分成三个维度进行讨论的。这三个维度，也是判断一个东西是否是“去中心化”的三把尺子。需要说明的是，这三把尺子，初看起来似乎缺一不可，但总体来说，它们彼此之间相互独立，详解

• 架构层： 在物理世界里，一个系统由多少台计算机组成？在这个系统运行的过程中，可以忍受多少台计算机的崩溃而系统依然不 * 受影响？
• 政治层： 有多少个人或者组织，对组成系统的计算机拥有最终的控制权？

• 逻辑层： 从这个系统所设计的接口和数据结构来看，它更像一台完整的单一设备，还是更像一个由无数单位组成的集群？——这个维度可能比较抽象，不太好理解，我们可以用另一种比较简单的方式来做判断： 如果把这个系统分成两半，两部分里同时包含生产者和消费者，那么这两部分能继续作为独立单元完整地运行下去吗？
  这三把尺子，一把用来测量架构层的系统设计、一把用来测量政治层的掌控权力、一把用来测量逻辑层的所属形态。　
  　

  去中心化优点

  容错性 ： 去中心化系统不太可能因为某一个局部的意外故障而停止工作，因为它依赖于许多独立工作的组件，它的容错能力更强。
  抗攻击性 ： 对去中心化系统进行攻击破坏的成本相比中心化系统更高。从经济效益上来说，这是抢劫一个房子和抢劫一片村庄的差别。
  抗勾结性： 去中心化系统的参与者们，很难相互勾结。而传统企业和政府的领导层，往往会为了自身的利益，以损害客户、员工和公众利益的方式，相互勾结。
  去中心化的缺点则是效率的降低，去中心化程度越高，各个节点间达成共识越难。

POW:Proof of Work 工作证明

POW 采用提高提议成本的方式，每一个节点在提出提议时必须解决一个难题（消耗时间），谁先解决谁说了算。比特币所用的 POW 可简述为：填充区块的随机数字段，使其区块 hash 满足给定数量前导 0 的哈希值的过程。要求的前导 0 的个数越多，代表难度越大；同时为了保证出块的速度，动态调整了全网难度值。

POS:Proof of Stake 股权证明

POW 造成了计算机算力浪费，POS 在一定程度弥补了这一点，股权证明要求用户证明拥有某些数量的代币和持有时间，币龄（代币数量乘以持有时间）越高提议权越大，一旦达成提议则持有时间清零, 币龄清空, 没有币就没有话语权。

POW+POS
集合 POW 和 POS 的优点, 使用 POW 证明方式, 利用 POS 股权降低挖矿难度, 即节点提议难度和股权数成反比。

POA:Proof-of-Authority 权威证明

由一些有许可（权威）的节点负责提议，这些节点被称为 “验证者”（Validator）
验证者必须满足以下三个条件：
其身份必须得到正式验证，信息可在公有可用域中交叉验证。
其资格必须难以获得，这样所得到的权威才弥足珍贵（例如，潜在的验证者需要获得公证书）。
建立权威的检查和程序必须完全统一。
使用 POA，每个个体都具有变成验证者的权利，因此存在一旦获取就保持验证者位置的动机。通过对身份附加一个声誉，可以鼓励验证者去维护交易的过程。因为验证者并不希望让自己获得负面声誉，这会使其失去来之不易的验证者地位。

DPOS:Delegated Proof of Stake 委任权益证明

POS 中可能存在提议权把握在少数拥有大量代币的节点手中,DPOS 能够避免 "集权" 的产生, 让每一个节点按一定规则投票选出一定数量的节点来代表整个集群，选出来的节点权利对等，DPoS 机制类似于股份制公司，普通股民进不了董事会，要投票选举代表（受托人）代他们做决策。

PBFT:Practical Byzantine Fault Tolerance 实用拜占庭容错算法

pbft 算法主要是为了解决拜占庭将军问题，假设网络没有问题但是可能有恶意节点（不能超过 1 /3），基本流程：

1. 客户端发送请求给主节点
2. 主节点广播请求给其它节点，节点执行 pbft 算法的三阶段共识流程（预准备阶段，准备阶段，提交阶段）。
3. 节点处理完三阶段流程后，返回消息给客户端。
4. 客户端收到来自 f+1 个节点的相同消息后，代表共识已经正确完成。

PAXOS 算法

指系统中存在故障，但不存在恶意节点场景（即可能消息丢失或重复，但无错误消息）下的共识达成问题。
算法中将节点分为三种类型：
proposer：提出一个提案，等待大家批准为结案。往往是客户端担任该角色；
acceptor：负责对提案进行投票。往往是服务端担任该角色；
learner：被告知结案结果，并与之统一，不参与投票过程。可能为客户端或服务端。
基本过程包括 proposer 提出提案，先争取大多数 acceptor 的支持，超过一半支持时，则发送结案结果给所有人进行确认，learner 确认一个提议是否被采纳。一个潜在的问题是 proposer 在此过程中出现故障，可以通过超时机制来解决。

RAFT 算法

Raft 算法是 Paxos 算法的一种简化实现。包括三种角色：leader、candidate 和follower，其基本过程为：
Leader 选举：每个 candidate 提出选举方案，得票最多者被选为 leader；
同步：由 leader 处理所有提议，并分发给 follower，各个节点与 leader 进行同步。

ZAB 算法

原子消息广播协议，与 RAFT 算法稍有区别，RAFT 主节点提出一个提议，不需要等待 follower 确认就可以提出下一个，每隔一段时间批量确认，而 ZAB 是确认一条提议才能处理下一条（原子性）。

共识算法总结

1. 本质是解决不同节点间的 一致性问题 ；　　
2. 明确了哪个节点 可以提议 或者同时提议时 选择哪个提议 　　
3. 一般假定信道没有问题，但是可能存在恶意节点，要 处理节点作恶
4. 对于 故障节点处理 和如何 同步恢复 的问题