FLP不可能原理/CAP原理/ACID原则

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

FLP不可能原理实际上告诉人们，不要浪费时间，去为异步分布式系统设计在任意场景下都能实现共识的算法。

后期补充

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

·一致性：任何操作应该都是原子的，发生在后面的事件能看到前面事件发生导致的结果，注意这里指的是强一致性；
·可用性：在有限时间内，任何非失败节点都能应答请求；

·分区容忍性：网络可能发生分区，即节点之间的通信不可保障。

下面三个应用场景。

1.弱化一致性

对结果一致性不敏感的应用，可以允许在新版本上线后过一段时间才最终更新成功，期间不保证一致性。例如网站静态页面内容、实时性较弱的查询类数据库等，简单分布式同步协议如Gossip，以及CouchDB、Cassandra数据库等，都是为此设计的。

2.弱化可用性

对结果一致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务。MongoDB、Redis、MapReduce等是为此设计的。Paxos、Raft等共识算法，主要处理这种情况。

3.弱化分区容忍性

现实中，网络分区出现概率较小，但较难完全避免。两阶段的提交算法，某些关系型数据库及ZooKeeper主要考虑了这种设计。实践中，网络可以通过双通道等机制增强可靠性，达到高稳定的网络通信。

ACID原则

ACID原则指的是：Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性），用了四种特性的缩写。

ACID也是一种比较出名的描述一致性的原则，通常出现在分布式数据库领域。具体来说，ACID原则描述了分布式数据库需要满足的一致性需求，同时允许付出可用性的代价。

ACID特征如下：

·Atomicity：每次操作是原子的，要么成功，要么不执行；

·Consistency：数据库的状态是一致的，无中间状态；

·Isolation：各种操作彼此之间互相不影响；

·Durability：状态的改变是持久的，不会失效。

与ACID相对的一个原则是BASE（Basic Availability，Soft-state，Eventual Consistency）原则，牺牲掉对一致性的约束（但实现最终一致性），来换取一定的可用性。

分布式系统的核心问题

主要内容:

一致性问题 共识问题

 

一致性:分布式集群中多个服务节点,对给定的操作,根据给定的协议,对处理结果对外保持一致. 不在乎结果是否正确,而是保证对外呈现的状态一致.所有节点失败也是一种一致.

 

引起不一致的因素:

节点间网络通信的不可靠,消息延迟,消息乱序,内容错误.

节点处理时间无法保证: 结果可能错误,或者节点宕机.

 

满足一致性的要求:

1. 有限时间完成请求的处理2.不同节点完成的结果相同.3决策的结果必须是某个节点提出的提案.

 

强一致性需要 顺序保证. 时钟

 

共识:对某一操作,达成一直的过程.通常达成这个一过程需要集群中的节点进行广播投票.

但是由于分布式节点间的不稳定: 网络不可靠,节点宕机,假消息等.达成共识并不容易.

 

针对如上不稳定的情况,把故障分为:非拜占庭错误(出现消息不响应,但是消息不会被篡改)和拜占庭错误(存在伪造消息的情况).

 

共识算法:

CFT类 针对非拜占庭错误有: PAXOS 算法.Raft算法.

 容错较好,处理快,保证不超过一半节点故障.

BFT类 针对拜占庭错误有: PBFT 确定性算法,POW 工作量证明的概率算法.

 

 

FLP不可能原理: 异步系统,不存在 任意场景下都能实现共识的算法.

 

分布式同步:系统各个节点时钟误差存在上限,消息传递必须在规定时间内完成,否则认为失败.(传统的分布式中,统一时钟,超时失败等都是同步)

 

分布式异步:系统各个节点时钟存在较大差距,消息传递时间任意长(无法判断节点故障还是网络延迟)

 

 

CAP 一致性 :分布式计算系统不可能同时保证 强一致性,高可用性,高分区容忍性.

折中选择:

弱化一致性:对结果不敏感的应用可以允许最终一致. CouchDB

弱化可用性:对结果一致性敏感,银行,当系统故障时会拒绝服务.MongoDB , Redis,MapReduce 为此设计. PAXOS 等共识算法主要处理这种情况. 可能存在无法提供可用结果的情况,同时允许部分节点离线.

弱化分区容忍性: 网络分区出现概率较小, 两阶段提交算法,关系型数据库,ZK主要考虑这种情况设计的.实践中网络可用是双通道,弱化网络不稳定因素.

 

 

PAXOS 算法:

节点分为三种角色:

① 提案者:提出提案,系统提案都有自增ID,(往往是客户端担任)

② 接受者:对提出的提案进行投票(服务端)

③ 学习者:对投票传播学习,不参与投票

约束条件:

①保证决议结果是正确的,不会出现错误.只有被提案者提出的提案才会被投票接受.一次执行中被多数接受的提案成为最终决议

②保证决议在有限时间内完成,决议总会产生,并且学习者会接受决议

过程: