分布式基础-分布式一致性之CAP和BASE理论

本文主要参考自相关书籍和网络文章，并附上自身的一些理解，如有遗漏或错误，还望海涵并指出。谢谢！

一.分布式一致性

分布式一致性指的是在分布式系统下，数据所具有的一致性。先从单机的ACID模式看起：

1.传统的单机ACID模式

在传统的Web应用中，许多项目仍然采用着单机模式的项目架构。而ACID特性是单机的关系型数据库中，保证事务所需的四大特性：

1.Atomicity（原子性）

一个事务的所有操作，要么全部完成，要么全部不完成。

所谓事务，是指由一系列数据操作所组成的完整逻辑过程。比如银行转账事务由两个操作组成：从源账户扣除金额，以及向目标账户增加金额。

2.Consistency（一致性）

指事务开始之前和事务结束之后，数据的完整性约束没有被破坏。

包含两层含义：

a)数据库机制层面，事务执行前后，数据能符合设置的约束，如唯一约束、外键约束；

b)业务层面，由应用开发人员保证业务一致性。还是以银行转账为例，A、B两个账号，转账之前和之后，A、B两个账号余额总额必须一致。

3.Isolation（隔离性）

数据库能够防止由于多个并发事务交叉执行而导致数据的不一致。

4.Durability（持久性）

指事务结束后，对数据的修改是永久的，不会回滚到之前的状态。

ACID模型是单机的关系型数据库最经典的一个模型，当出现分布式架构时，ACID模型就会出现错误，所以随着分布式架构的产生，新的理论和模型也随之出现。

2.分布式架构演进

我们知道，随着应用请求的增多和并发压力的增大大，系统架构开始向分布式架构开始演进。

存储系统作为基础设施，在单机上持久化是远远不够的，我们需要将数据复制到多台机器上以提升系统的可用性和可靠性。

例如下图中，MySQL做了主从复制架构，形成了一个4台机器组成的分布式系统：

既然存在数据的复制，那么就肯定会出现从服务器和主服务器间数据不一致的问题，例如网络中断导致了从服务器无法及时同步主服务器数据，这就产生了分布式一致性问题。

3.分布式一致性等级

1.强一致性

是最严格的一致性等级，要求任何读取操作都能读取到最新的值，也就是说，要求任何写入操作立即同步给所有机器。

2.弱一致性

这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不久承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。Zookeeper集群保证了弱一致性。

3.最终一致性

最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。例如Redis集群保证的是最终一致性。

二.CAP理论

CAP原理是分布式系统中最重要的基本原理之一，是由计算机科学家Eric Brewer提出的，即在分布式计算机系统无法同时提供以下全部三个服务，而最多只能同时保证三者之中的两者成立。

1. 强一致性（Consistency）：同一时间可在分布式系统所有计算机看到是相同的数据
2. 可用性（Available）：分布式系统能对外提供可用的服务
3. 分区容错性（Partition tolerance）：系统的机器间可以存在网络分区（网络故障）

需要注意的是，CAP理论中的一致性指的是强一致性，也就是任一时刻，从分布式集群中的任何机器读取到的数据都是一致的。

CAP的常见模型

1.CA模型

CA模型是指不存在网络分区时，可以保证C一致性与A可用性。但是这种情况在分布式系统中不成立，因为网络故障是有很大可能发生的，所以通常CA这种模型只出现在单机服务中，在分布式系统中通常是选择CP模型或AP模型。

1.CP模型

CP模型指的是在P网络分区发生时，保证C强一致性，而不保证A可用性。

这种模型多用在需要保证完全数据正确的场合，例如zookeeper集群保证CP，即任何时刻对zookeeper的访问请求能得到一致性的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务的可用性。从实际情况来分析，在使用zookeeper获取服务列表时，如果zk正在选举或者zk集群中半数以上的机器不可用，那么将无法获取数据。所以说，zk不能保证A服务可用性。

2.AP模型

AP模型指的是在网络分区P发生时，保证A可用性，而不保证C一致性。

这种模型多用在不需要保证数据完全正确，但是需要高可用的场合，例如Redis读写分离集群，采用哨兵机制时，存在主节点宕机了，但是数据还没有被从节点所同步，哨兵这时将次节点设置为住节点，那么就出现了数据不一致的问题。需要注意的是，Redis可以保证最终一致性（网络连接恢复后会对数据进行同步）。

三.BASE理论

BASE理论是基于CAP理论的进一步优化，在BASE理论中，允许网络分区发生时，牺牲强一致性，而使得分布式系统具有弱一致性和可用性，而不像CAP理论那样只能在强一致性和可用性之间选择一者。

1. BA（Basically Available）：系统可以提供最基础的功能，保证基本可用
2. S（Soft State）：软状态，即系统可以有一段时间是不同步的
3. E（Eventually Consistent）：数据要保证最终是一致的

1.基本可用

什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言，在响应时间或功能上出现差异：

1. 响应时间增加

响应时间增加了，可能是因为系统正在进行故障转移或者是重连等

2. 只保证基本功能

在发生了异常情况，并不一定要将所有功能都下线掉，可以是提供异常页面或者是通过请求降级到预设的服务页面

2.软状态

软状态是相对于硬状态而言的。硬状态要求多个节点的数据副本都是一致的。

而软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

3.最终一致性

软状态只能存在与较短的时间中，而不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

ACID 要求强一致性，通常运用在传统的单机数据库系统上。而 BASE 要求最终一致性，通过牺牲强一致性来达到可用性，通常运用在大型分布式系统中。

在实际的分布式场景中，不同业务单元和组件对一致性的要求是不同的，因此 ACID 和 BASE 往往会结合在一起使用。