文章目录
区块链系统，首先是一个分布式系统。
一、一致性问题
一致性问题是分布式领域最为基础也是最重要的问题。如果分布式系统能实现“一致”，对外就可以呈现为一个完美的、可扩展的“虚拟节点”，相对物理节点具备更优越性能和稳定性。这也是分布式系统希望能实现的最终目标。
1.定义
一致性（consistency）：指对于分布式系统中的多个服务节点，给定一系列操作，在约定协议的保障下，试图使得它们对处理结果达成“某种程度”的认同。
理想情况下，如果各个服务节点严格遵循相同的处理协议，构成相同的处理状态机，给定相同的初始状态和输入序列，则可以保障在处理过程中的每个环节的结果都是相同的。
注：一致性并不代表结果正确与否，而是系统对外呈现的状态一致与否。
2.一致性要求
分布式系统达成一致的过程，应该满足：
- 可终止性（termination）：一致的结果在有限时间内能完成；
- 约同性（agreement）：不同节点最终完成决策的结果是相同的；
- 合法性（validity）：决策的结果必须是某个节点提出的提案。
事件发生的先后顺序十分重要，这也是解决分布式系统领域很多问题的核心秘诀：把多件事情进行排序，而且这个顺序还得是大家都认可的。
3.带约束的一致性
越强的一致性要求往往会造成越弱的处理性能，以及越差的可扩展性。
一般来讲，强一致性（strong consistency）主要包括下面两类：
-
顺序一致性（sequential consistency）：是一种比较强的约束，保证所有进程看到的全局执行顺序（total order）一致，并且每个进程看自身的执行顺序（local order）跟实际发生顺序一致。顺序一致性实际上限制了各进程内指令的偏序关系，但不在进程间按照物理时间进行全局排序；
-
线性一致性（linearizability consistency）：在顺序一致性前提下加强了进程间的操作排序，形成唯一的全局顺序，是很强的原子性保证。但是比较难实现，目前基本上要么依赖于全局的时钟或锁，要么通过一些复杂算法实现，性能往往不高。
实现强一致性往往需要准确的计时设备。
可以适当地放宽对一致性的要求，从而降低系统实现的难度。例如在一定约束下实现所谓最终一致性（eventual consistency），即总会存在一个时刻（而不是立刻），让系统达到一致的状态。大部分Web系统实现的都是最终一致性。相对强一致性，这一类在某些方面弱化的一致性都笼统称为弱一致性（weak consistency）。
二、共识算法
一致性往往指分布式系统中多个副本对外呈现的数据的状态。共识则描述了分布式系统中多个节点之间，彼此对某个状态达成一致结果的过程。因此，一致性描述的是结果状态，共识则是一种手段。达成某种共识并不意味着就保障了一致性。
对于分布式系统来讲，各个节点通常都是相同的确定性状态机模型（又称为状态机复制问题，state-machine replication），从相同初始状态开始接收相同顺序的指令，则可以保证相同的结果状态。因此，系统中多个节点最关键的是对多个事件的顺序进行共识，即排序。
1.问题与挑战
一般地，把出现故障（crash或fail-stop，即不响应）但不会伪造信息的情况称为“非拜占庭错误”（non-byzantine fault）或“故障错误”（Crash Fault）；伪造信息恶意响应的情况称为“拜占庭错误”（Byzantine Fault），对应节点为拜占庭节点。
2.常见算法
根据解决的是非拜占庭的普通错误情况还是拜占庭错误情况，共识算法可以分为Crash Fault Tolerance（CFT）类算法和Byzantine Fault Tolerance（BFT）类算法。
对于非拜占庭错误：已经存在一些经典的解决算法，包括Paxos、Raft及其变种等。这类容错算法往往性能比较好，处理较快，容忍不超过一半的故障节点。
对于拜占庭错误：一般包括PBFT（Practical Byzantine Fault Tolerance）为代表的确定性系列算法、PoW为代表的概率算法等。对于确定性算法，一旦达成对某个结果的共识就不可逆转，即共识是最终结果；而对于概率类算法，共识结果则是临时的，随着时间推移或某种强化，共识结果被推翻的概率越来越小，成为事实上的最终结果。拜占庭类容错算法往往性能较差，容忍不超过1/3的故障节点。
此外，XFT（Cross Fault Tolerance）等改进算法可以提供类似CFT的处理响应速度，并能在大多数节点正常工作时提供BFT保障。
三、FLP不可能原理
1.定义
FLP不可能原理：在网络可靠，但允许节点失效（即便只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确定性共识算法。
不要浪费时间，去为异步分布式系统设计在任意场景下都能实现共识的算法。
2.定理的理解
同步 ：指系统中的各个节点的时钟误差存在上限；并且消息传递必须在一定时间内完成，否则认为失败；同时各个节点完成处理消息的时间是一定的。对于同步系统，可以很容易地判断消息是否丢失。
异步： 指系统中各个节点可能存在较大的时钟差异，同时消息传输时间是任意长的，各节点对消息进行处理的时间也可能是任意长的，这就造成无法判断某个消息迟迟没有被响应是哪里出了问题。
FLP不可能性在原始论文中以图论的形式进行了严格证明。FLP原理实际上说明对于允许节点失效情况下，纯粹异步系统无法确保一致性在有限时间内完成。即便对于非拜占庭错误的前提下，包括Paxos、Raft等算法也都存在无法达成共识的情况，只是在工程实践中这种情况出现的概率很小。
科学告诉你什么是不可能的；工程则告诉你，付出一些代价，可以把它变成可行。
四、CAP原理
1.定义
CAP原理：分布式计算系统不可能同时确保以下三个特性：一致性（Consistency）、可用性（Availability）和分区容忍性（Partition），设计中往往需要弱化对某个特性的保证。
-
一致性：任何操作应该都是原子的，发生在后面的事件能看到前面事件发生导致的结果，注意这里指的是强一致性；
-
可用性：在有限时间内，任何非失败节点都能应答请求；
-
分区容忍性：网络可能发生分区，即节点之间的通信不可保障。
当网络可能出现分区的时候，系统是无法同时保证一致性和可用性的。要么，节点收到请求后因为没有得到其他节点的确认而不应答（牺牲可用性），要么节点只能应答非一致的结果（牺牲一致性）。
由于大多数时候网络被认为是可靠的，因此系统可以提供一致可靠的服务；当网络不可靠时，系统要么牺牲掉一致性（多数场景下），要么牺牲掉可用性。
注：网络分区是可能存在的，出现分区情况后很可能会导致发生“脑裂”，多个新出现的主节点可能会尝试关闭其他主节点。
2.应用场景
既然CAP三种特性不可同时得到保障，则设计系统时必然要弱化对某个特性的支持。那么可能出现下面三个应用场景。
- 弱化一致性
对结果一致性不敏感的应用，可以允许在新版本上线后过一段时间才最终更新成功，期间不保证一致性。例如网站静态页面内容、实时性较弱的查询类数据库等，简单分布式同步协议如Gossip，以及CouchDB、Cassandra数据库等，都是为此设计的。
- 弱化可用性
对结果一致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务。MongoDB、Redis、MapReduce等是为此设计的。Paxos、Raft等共识算法，主要处理这种情况。在Paxos类算法中，可能存在着无法提供可用结果的情形，同时允许少数节点离线。
- 弱化分区容忍性
现实中，网络分区出现概率较小，但较难完全避免。两阶段的提交算法，某些关系型数据库及ZooKeeper主要考虑了这种设计。实践中，网络可以通过双通道等机制增强可靠性，达到高稳定的网络通信。
五、ACID原则
ACID原则指的是：Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性），用了四种特性的缩写。
ACID原则描述了分布式数据库需要满足的一致性需求，同时允许付出可用性的代价。
- Atomicity：每次操作是原子的，要么成功，要么不执行；
- Consistency：数据库的状态是一致的，无中间状态；
- Isolation：各种操作彼此之间互相不影响；
- Durability：状态的改变是持久的，不会失效。
与ACID相对的一个原则是BASE（Basic Availability，Soft-state，Eventual Consistency）原则，牺牲掉对一致性的约束（但实现最终一致性），来换取一定的可用性。
