1 CAP #
1.1 CAP(1999) #
CAP(Consistency/Availability/Partition Tolerance)，分别代表：强一致性、可用性和分区容忍性：
- 强一致性：即在分布式系统中的同一个数据多副本情形下，对于数据的更新操作体现的效果与只有单份数据是一样的；
- 可用性：客户端在任何时刻对大规模数据系统的读/写操作都应该保证在限定延时内完成；
- 分区容忍性：在大规模分布式数据系统中，网络分区现象，即分区的机器无法进行网络通信的情况是必然会发生的，所以系统应该能够在这种情况下仍然继续工作。
CAP 最初是由 Eric Brewer 于1999年首先提出的，他同时证明了：对于一个大规模分布式数据系统来说，CAP三要素不可兼得，同一个系统至多只能实现其中的两个，而必须放宽第3个要素来保证其他两个要素被满足。即，要么AP，要么CP，抑或AC，但是不存在CAP，这就是CAP原则的精髓所在。一般在网络环境下，运行环境出现网路分区是不可避免的，所以系统必须具备分区容忍性，于是一般在此种场景下设计大规模分布式系统时，架构师往往在AP和CP中进行权衡和选择，有所强调，有所放弃。
1.2 为何在分布式环境下 CAP 三者不可兼得？ #
假设存在网络分区的情形，若已得到P，即容忍网络分区的存在，那么C和A是否可以兼得？
情形一：如果这个分布式系统中数据无副本，那么系统必然满足强一致性条件，因为只有独本数据，不会出现数据不一致的可能。此时C和P两要素具备，但是如果系统发生了网络分区状况或者机器宕机，必然导致某些数据不可访问，此时可用性条件时不能被满足的，即在此情形下获得了CP系统，但CAP不能同时满足。
情形二：如果系统中数据有副本，假设变量x存在两份副本并分别存储在不同机器上，最初数据保持一致，其值都是v1。
- 在Time=t1时刻，在机器1上发生对x的数值更新操作，此操作要将x的值赋为v2；
- 时间推移到Time=t2时刻，机器1上的x已经被赋予新值v2：
- 如果此时未发生网络分区状况，系统可以将x的新值v2同步到机器2，达到数据一致性要求；
- 如果此时发生了网络分区导致两台机器无法通信，那么无法将x的新值同步到机器2，这个时刻我们不得不在C或者A之间做个权衡和选择：
- 如果希望系统高可用(选择A)，那么对于读取机器2上的x的查询请求必须在限定时间内返回值，此时返回的并非是最新的值v2，所以出现了数据不一致的问题(抛弃C)；
- 如果选择强一致性(选择C)，那么在两台机器恢复通信并将数据同步到一致状态前，对于机器2的x读请求必须予以拒绝，此时无法保证系统的可用性(抛弃A)；
- 所以，不论选择哪一个，必然以牺牲另外一个因素作为代价，也就是说，要么AP，要么CP，但是没有完美的CAP。
1.3 CAP Reloaded(2012) #
Eric Brewer 在2012年发表的文章中指出：实践过程中应用CAP理论时不得不在三要素中选择两个而牺牲另外一个的做法具有误导性，其具体误导性体现在三个方面：
- 首先，在实际系统中，网络分区(P)出现的概率是很小的，并不应该为了容忍这种小概率事件而在设计之初就选择放弃A或者放弃C，对于大多数没有出现网络分区的状况，还是应该尽可能兼顾AC两者，即正常状况下应该兼顾CAP三要素；
- 其次，即使是必须在AC之间作出取舍的时候，也不应该是粗粒度地在整个系统级别进行取舍，即整个系统要么取A舍C，要么取C舍A，而是应该考虑系统中存在不同的子系统，甚至应该在不同的系统运行时或者在不同的数据间进行灵活的差异化的细粒度取舍，即可能对不同子系统采取不同取舍策略，在不同的系统运行时对不同数据采取不同的取舍策略；
- 再次，CAP三者并非是绝对二元式地有或者没有，而是应该将其看作连续变量，即可以看作在一定程度上的有或者没有，比如可用性指标中(A)延时长度多少算可用这都是可以看作连续变量的，类似地，C和P也可以如此看待，在实际进行取舍时并非加以完全舍弃，而是可以考虑在多大程度上进行舍弃。
考虑到以上实际应用CAP理论时的误导性，因此可以采取如下的应用CAP策略：在绝大多数系统未产生网络分区的情形下，应该尽可能保证AC两者兼得，也即大多数情况下考虑CAP三者兼得，当发生网络分区的情形下，系统应该能够识别这种状况并对其进行正确处理，具体而言，应该分为3个步骤：
- 首先能够识别网络分区发生；
- 然后在网络分区场景下进入明确的分区模式，此时可能会限制某些系统操作；
- 最后在网络分区解决后能够进行善后处理，即恢复数据的一致性或者弥补分区模式中产生的错误。
2 ACID原则 #
ACID 是关系数据库系统采纳的原则：
- 原子性(Atomicity)：是指一个事务要么全部执行，要么完全不执行。也就是不允许一个事务只执行了一半就停止。以银行转账为例，这是一个典型的事务，它的操作可以分成几个步骤：首先从A账户取出要转账的金额，A账户扣除相应的金额，之后将其转入B账户的户头，B账户增加相同的金额。这个过程必须完整地执行，否则整个过程将被取消，回退到事务未执行的状态。不允许出现从A账户已经扣除金额，而没有打入B账户这种情形。
- 一致性(Consistency)：事务在开始和结束时，应该始终满足一致性约束条件。比如系统要求 A+B=100，那么事务如果改变了A的数值，则B的数值也要相应修改来满足这种一致性要求；这里需要注意的是，尽管CAP和ACID都有关于一致性的定义，但是两者的含义是不同的，即两个C代表了不同含义，这点要特别注意。
- 事务独立(Isolation)：如果有多个事务同时执行，彼此之间不需要知晓对方的存在，而且执行时互不影响，不允许出现两个事务交错、间隔执行部分任务的情形，也即事务之间需要序列化执行。
- 持久性(Durability)：事务的持久性时指事务运行成功之后，对系统状态的更新是永久的，不会无缘由地回滚撤销。
3 BASE原则 #
数据库系统采纳 ACID 原则，获得可靠性和强一致性。而大多数大数据环境下的云存储系统和 NoSQL 系统则采纳 BASE 原则：
- 基本可用(Basically Available)：在绝大多数时间内系统处于可用状态，允许偶尔的失败；
- 软状态或者柔性状态(Soft State)：数据状态不要求在任意时刻都完全保持同步。到目前为止软状态并无一个统一明晰的定义，但是从概念上是可理解的，即处于有状态(State)和无状态(Stateless)之间的中间状态。
- 最终一致性(Eventual consistency)：与强一致性相比，最终一致性是一种弱一致性，尽管软状态不要求任意时刻数据保持一致同步，但是最终一致性要求在给定时间窗口内数据会达到一致状态。
4 CAP/ACID/BASE 三者的关系 #
ACID 和 BASE 原则是在明确提出 CAP 理论之前关于如何对待可用性和强一致性的两种完全不同的设计哲学：
- ACID 更强调数据一致性，这是传统数据库设计的思路；
- BASE 更强调可用性，弱化数据一致性的概念，这是互联网时代对于大规模分布式数据库系统的一种需求，尤其是其中的软状态和最终一致性，这两者是在容忍网络分区情形下强调可用性的具体手段。
CAP 和 ACID 的明显差异如下：
- 两者中尽管都包含一致性，但是两者含义不同，ACID 中的 C 指的是对操作的一致性约束，而 CAP 中的 C 指的是数据的强一致性(多副本对外表现类似于单副本)，所以可以将 CAP 中的 C 看作一致性约束的一种，即 CAP 中的 C 是 ACID 中的 C 所涵盖语义的子集。在出现网络分区情形下，很明显 ACID 中的 C 所要求的一致性约束是无法保证的，所以在网络分区解决后需要通过一定手段来恢复 ACID 中要求的一致性。
- 当出现网络分区时，ACID 中事务独立(I)只能在多个分区中的某个分区执行，因为事务的序列化要求通信，而当网络分区时明显无法做到这点，所以只能在某个分区执行。
- 当出现网络分区时，多个分区都可以各自进行 ACID 中的数据持久化(D)操作，当网络分区解决后，如果每个分区都提供持久化记录，则系统可以根据这些记录发现违反 ACID 一致性约束的内容并给予修正
总而言之，当 CAP 中的 P 出现时，如果每个网络分区都尽可能执行 ACID，那么对于网络分区问题解决后数据的一致性恢复是有很大帮助的。