浅谈CAP+ACID+BASE理论

1. 背景

在大数据存储系统或者各类分布式系统，为了增加系统高可用性，往往会将同一数据存储多份副本。常规做法是三副本，数据复制成多份，带来了很多好处：

1. 高可用性：即使因为机器故障、宕机等原因损失一副本，仍然有其他二个副本提供服务
2. 增加读操作的并发性：比如对于三副本，常用选举算法选出leader-支持读写, 其他两个副本作为Follower可以支持读操作
   带来上述好处的同时，也引入了很多问题，比如：
3. 同一数据存在多个副本，在并发的众多客户端读/写请求下，如何维护数据一致性
4. 三副本如何复制数据？在网络分区异常情况下，如何提供服务? 在网络分区结束后，如何处理不一致的数据等等

同时在面试一些候选人过程中，往往候选人会将CAP和ACID一些概念搞混，包括NoSQL系统很流行的时候，引入了BASE理论，本文做一些总结

2. CAP

CAP是“”Consistency/Availability/Partition Tolerance”的一种简称，C：强一致性: 场景是分布式系统中的同一数据，采用多副本设计，对于数据的更新操作体现出的效果与只有单副本是一样的。即虽然是多副本，基于读写语义，我们可以证明在各种情况下，和单副本表现均一致，这是强一致性。换言之，只有能找到一种场景，和单副本表现不一致，那就不是强一致性，不满足C
A： 可用性: 客户端在任何时刻对大规模分布式数据系统的读/写操作保证在有限时间内完成，即使各种故障发生，服务能够在有限时间内提供服务，尽量可用
P： 分区容忍性：网络分区现象，即分区间的机器无法进行网络等

2.1 阶段一：1999

Eric Brewer于1999年首先提出了CAP，同时证明了：对于一个大规模分布式数据系统，CAP三要素不可兼得，含义：同一个系统至多只能实现其中的两个，而必须舍弃第3个要素来保证其他两个要素被满足。即要么AP，要么CP，抑或AC，但是不存在CAP。

证明其实很简单，比如P发生了，即网络分区，在多副本场景下，为了保证C，三副本数据强一致性，那么必然需要等待网络分区恢复，那么不能及时提供服务，不保证A；
如果为了保证A，即尽快服务，那么因为网络分区无法通信，多副本数据无法达成强一致性，即违反了C；其他证明类似

2.2 阶段二：2012

Eric Brewer2012年发表的文章中CAP Twelve Years Later: How the ＂Rules＂ Have Change.IEEE Computer Society.2012, 重新阐述了CAP理论，原因是在1999年提出CAP后，因为分布式系统天然P存在，很多设计者，就在AP或者CP选择，Eric Brewer认为系统设计不够完善，存在很多误导性，本次要点总结如下：

1. 在实际系统中，网络分区（P）出现的概率比较小的，并不是一直存在，并不能因为小概率出现的P，就不考虑A/C, 因为A/C本身其实对于系统很重要。
2. 分布式数据系统其实很复杂，往往包含很多子系统或者子模块，因此不应该粗粒度地在整个系统级别进行取舍，即整个系统要么取A不考虑C，要么取C不考虑A，因此设计系统更应该更细粒度，比如出现网络分区，某些子系统或者子模块还可以满足AC，或者针对某些核心数据，需要有特殊的设计和考虑
3. CAP三者并非是二元式地有或没有，而应该是连续变量，因此CAP三个属性都是连续的值，而不是二值选项。Availability可以是0~100，Consistency也可以强弱不同，分区是否发生也并非简单的二值。

3. BASE

大数据环境下的云存储系统，特别是很多NoSQL系统则采纳往往BASE原则。BASE原则是指：
基本可用（Basically Available）：大多数时间内系统处于可用状态，即不要求所有时间系统都持续提供状态，但是允许偶尔的系统不服务，比如读写请求失败
软状态或者柔性状态（Soft State）： 是指系统的数据不要求在任何时刻都完全保持同步。即在数据处理过程中，允许这个过程，存在数据状态暂时不一致的情况，但是最终数据会一致。
最终一致性（Eventual Consistency）。和强一致性相比，最终一致性是一种弱一致性，不要求如何时刻数据保持一致同步，但是要求在给定的时间窗口内数据达到一致。

4. ACID

ACID是事务的基本属性：

• 原子性（Atomicity）：类似原子操作，是指一个事务全部执行，保证单个事务要不成功，要不失败。不允许一个事务只执行了一半就停止。典型场景：比如用户A给用户B转账，一定不能出现如下场景：A账户少钱了，但是B账户没有增加钱；或者A账户没有扣钱，B账户却增加钱。
• 一致性（Consistency）：事务在开始和结束时，需要始终满足一致性约束条件。比如系统要求A+B=100，那么事务如果改变了A的数值，则B的数值也要相应修改来满足这种一致性要求；
• 隔离性（Isolation）：如果有多个事务同时执行，彼此之间不需要知晓对方的存在，而且执行时互不影响，不允许出现两个事务交错、间隔执行部分任务的情形；
• 持久性（Durability）：事务运行成功以后，对系统状态的更新是永久的，不会回滚撤销，即使宕机也需要有方式恢复

5. 关系

1. CAP和BASE是一个维度的定义，本身是集中在系统本身，比如CAP的C强一致性，和BASE的最终一致性，都属于(分布式)系统探讨的一致性模型，一致性模块定义很多，这个话题需要单独探讨
2. ACID本身是事务的属性和基本定义，抛开事务和数据库其实本没有意义。比如ACID的C一致性，更强调数据库从一种合法的状态变迁为另外一种合法状态，需要满足各种约束，比如数据库中定义的完整性约束、Check约束、唯一约束。而CAP的C在存在单副本或者多副本，从客户端的视角来看读写的语义
3. 但是本身ACID和CAP、BASE又有一定联系，比如目前非常流行的分布式数据库架构，当采用多副本，自然涉及到CAP的定义，而分布式数据库本身也要支持事务，即满足ACID。比如当出现网络分区(CAP的P)，ACID的实现也自然受影响和考虑