分布式之cap、base理论、flp不可能原理、一致性问题、共识算法

一、CAP理论

CAP理论：在一个分布式系统中，最多只能满足C、A、P中的2个。

CAP含义：

C：Consistency 一致性：同一数据的多个副本是否实时相同。all nodes see the same data at the same time

A：Availability 可用性：一定时间内，系统能返回一个明确的结果 则称为该系统可用。Reads and writes always succeed

P：Partition tolerance 分区容错性：分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。the system continues to operate despite arbitrary message loss or failure of part of the system

而通常情况下，我们都必须要满足AP，所以只能牺牲C。

牺牲一致性换取可用性和分区容错性。

牺牲一致性的意思是，把强一致换成弱一致。只要数据最终能一致就好了，并不要实时一致。

二、BASE理论

主要就是分布式系统中最CAP怎么取舍怎么平衡的一个理论

BA：Basic Available 基本可用  

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。

电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

基本可用BA和高可用HA的区别是：

1.响应时间可以更长。

2.给部分用户返回一个降级页面。返回降级页面仍然是返回明确结果。

S：Soft State：柔性状态。同一数据的不同副本的状态，不用实时一致。

E：Eventual Consisstency：最终一致性。 同一数据的不同副本的状态，不用实时一致，但一定要保证经过一定时间后最终是一致的。

在实际工程实践中，最终一致性存在以下五类主要变种

1.因果一致性（Causal consistensy）

因果一致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最新值，即不能发生丢失更新情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制

 2.读己之所写（read your writes）

读己之所写是指，进程A更新一个数据项之后，它自己总是能访问到更过后的最新值，而不会看到旧值。也就是说，对于单个数据获取值来说，其读取到的数据，一定不会比自己上次写入的旧。因此，读己之所写可以看作是一种特殊的因果一致性。

3.会话一致性（session consistency）

会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效会话中实现“读己之所写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据的最新值。

4.单调读一致性（Monotonic read consistency）

单调读一致性是指如果一个进程从系统中读取一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

5.单调写一致性（Monotonic write consistency）

单调一致性写是指，一个系统需要能够保证来自同一个进程的写操作被顺序低执行。

三、FLP

参考：https://zhuanlan.zhihu.com/p/70439273

1.FLP 不可能原理

FLP定理[1]是分布式理论中最重要的理论之一，它指出在最小化异步网络通信场景下，即使只有一个节点失败，也没有一种确定性的共识算法能够使得在其他节点之间保持数据一致。

这里的最小化异步通信网络是对纯粹的异步网络做了限制，这里的异步网络与我们编程中的异步同步不是一个概念，具体可以参考[5] 分布式网络及故障模型。

提出并证明该定理的论文《Impossibility of Distributed Consensus with One Faulty Process》是由 Fischer，Lynch 和 Patterson 三位科学家于 1985 年发表，该论文后来获得了 Dijkstra（就是发明最短路径算法的那位计算机科学家）奖。

一个正确的分布式算法需要满足两条性质：

• Safety：具备Safety性质的算法保证坏的事情绝对不会发生，例如对于满足Safety性质的分布式选主(Leader election)算法，绝对不会出现一个以上进程被选为Leader的情况。
• Liveness：具备Liveness性质的算法保证好的事情终将发生，即算法在有限的时间内可以结束。

综上，一个正确的分布式算法可以在指定的分布式系统模型中保证Safety和Liveness属性。

而FLP不可能原理则是在说，要保证Safety的话就一定会出现Liveness

2.针对这个定义，有几个名词解释：

 在分布式系统中的网络模型，同步和异步这两个术语存在特殊的含义

同步网络(synchronous network): 这里的同步网络和编程中的同步阻塞io和异步非阻塞io是两回事

i). 所有节点的时钟漂移有上限,

ii). 网络的传输时间有上限,

iii). 所有节点的计算速度一样.

这意味着整个网络按照round运行, 每个round中任何节点都要执行完本地计算并且可以完成一个任意大小消息的传输.

一个发出的消息如果在一个round内没有到达, 那么一定是网络中断造成的, 这个消息会丢失, 不会延迟到第二个round到达.

在现实生活中这种网络比较少, 尽管很少, 同步网络仍然是在计算机科学中是不可缺少的一个分析模型, 在这种模型下可以解决一些问题, 比如拜占庭式故障. 但我们每天打交道的网络大多都是异步网络.

异步网络(asynchornous network)

i)节点的时钟漂移无上限,

ii)消息的传输延迟无上限,

iii)节点计算的速度不可预料.

这就是我们打交道的网络类型. 在异步网络中, 有些故障非常难解决, 比如当你发给一个节点一个消息之后几秒钟都没有收到他的应答, 有可能这个节点计算非常慢, 但是也可能是节点crash或者网络延迟造成的, 你很难判断到底是发生了什么样的故障.

 四、一致性问题

https://wohugb.github.io/blockchain_guide/distribute_system/problem/

1.定义：

在分布式系统中，一致性(Consistency，早期也叫 Agreement)是指对于系统中的多个服务节点，给定一系列操作，在协议（往往通过某种共识算法）保障下，试图使得它们对处理结果达成某种程度的一致。

如果分布式系统能实现“一致”，对外就可以呈现为一个功能正常的，且性能和稳定性都要好很多的“虚处理节点”。

注意：一致性并不代表结果正确与否，而是系统对外呈现的状态一致与否，例如，所有节点都达成失败状态也是一种一致。

2.分布式系统中一致性面临的挑战

在实际的计算机集群系统中，存在如下的问题：

• 节点之间的网络通讯是不可靠的，包括任意延迟和内容故障；
• 节点的处理可能是错误的，甚至节点自身随时可能宕机；
• 同步调用会让系统变得不具备可扩展性。

3.满足一致性需要达到的条件

共识算法的正确性要求是在运行中满足以下条件：

• 终止性（Liveness）：所有正确进程最后都能完成决定。
• 协定性（Safety）：所有正确进程决定相同的值。
• 完整性（Integrity）：如果正确的进程都提议同一个值，那么所有正确进程最终决定该值。

4.带约束的一致性

做过分布式系统的读者应该能意识到，绝对理想的强一致性（Strong Consistency）代价很大。除非不发生任何故障，所有节点之间的通信无需任何时间，这个时候其实就等价于一台机器了。实际上，越强的一致性要求往往意味着越弱的性能。

一般的，强一致性（Strong Consistency）主要包括下面两类：

• 顺序一致性（Sequential Consistency）：Leslie Lamport 1979 年经典论文《How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs》中提出，是一种比较强的约束，保证所有进程看到的 全局执行顺序（total order）一致，并且每个进程看自身的执行（local order）跟实际发生顺序一致。例如，某进程先执行 A，后执行 B，则实际得到的全局结果中就应该为 A 在 B 前面，而不能反过来。同时所有其它进程在全局上也应该看到这个顺序。顺序一致性实际上限制了各进程内指令的偏序关系，但不在进程间按照物理时间进行全局排序。
• 线性一致性（Linearizability Consistency）：Maurice P. Herlihy 与 Jeannette M. Wing 在 1990 年经典论文《Linearizability: A Correctness Condition for Concurrent Objects》中共同提出，在顺序一致性前提下加强了进程间的操作排序，形成唯一的全局顺序（系统等价于是顺序执行，所有进程看到的所有操作的序列顺序都一致，并且跟实际发生顺序一致），是很强的原子性保证。但是比较难实现，目前基本上要么依赖于全局的时钟或锁，要么通过一些复杂算法实现，性能往往不高。

强一致的系统往往比较难实现。很多时候，人们发现实际需求并没有那么强，可以适当放宽一致性要求，降低系统实现的难度。例如在一定约束下实现所谓最终一致性（Eventual Consistency），即总会存在一个时刻（而不是立刻），系统达到一致的状态，这对于大部分的 Web 系统来说已经足够了。这一类弱化的一致性，被笼统称为弱一致性（Weak Consistency）。

5.常见共识算法（一致性算法）

故障（不响应）的情况称为“非拜占庭错误”

恶意响应的情况称为“拜占庭错误”（对应节点为拜占庭节点）。

针对非拜占庭错误的情况，一般包括 Paxos、Raft 及其变种。

对于要能容忍拜占庭错误的情况，一般包括 PBFT 系列、PoW 系列算法等。从概率角度，PBFT 系列算法是确定的，一旦达成共识就不可逆转；而 PoW 系列算法则是不确定的，随着时间推移，被推翻的概率越来越小。