CAP定理20年回首：时代变了吗？

前言

10年前的今天，Eric Brewer 博士发表*CAP Twelve Years Later—How the ‘Rules’ Have Changed*，原文上万字，翻译并摘要、附注如下：

CAP Twelve Years Later 摘要

CAP理论（CAP Theorem）断言任何基于分布式数据共享系统，最多只能满足数据一致性、可用性、分区容忍性三要素中的两个要素。但是通过显式处理分区情形，系统设计师可以做到优化数据一致性和可用性，进而取得三者之间的平衡。

Eric Brewer是 UC,Berkeley 的计算机科学教授，联系方式：brewer@cs.berkeley.edu

22年前，Eric Brewer在Principles of Distributed Computing大会上发表了CAP理论。2012年，作者在Computer杂志发表了回顾。

作者认为是三选二公式有误导性,CAP把三者的相互关系过分简单化了，强调没有必要为很小的概率去牺牲A和C。对分布式系统来说分区容忍性（P）是基本要求，但可用性和一致性在系统正常工作期间是好搭档，并非是矛盾。

引入 CAP 理论的十几年里，架构师和研究者已经以它为理论基础探索了各式各样新颖的分布式系统，甚至到了滥用的程度。NoSQL 运动也将 CAP 理论当作对抗传统关系型数据库的依据。

译注：NoSQL实践中广为人知的应该就是HBase和Cassandra了。

HBase是CAP中的CP系统，即HBase是强一致性的。（在默认不开启Region replica的情况下）

• HBase之所以是CP系统，和底层HDFS无关。它是CP系统，是因为每个Region同时只有一台RegionServer为它服务，对一个Region所有的操作请求，都由这一台Region server来响应，自然是强一致性的，跟单机的JVM差不多。
• 在这台RegionServer 挂掉的时候，它管理的Region会failover到其他Region Server时，需要根据WAL-log来redo，进行redo的Region这时候是Unavailable（不可用）的，Region需要分钟级恢复来提供服务，所以HBase降低了可用性，提高了一致性。

Cassandra拥有分散式架构：任何节点都能执行任何操作，它提供了CAP原理中的AP（可用性和分区可容忍性）。

此外，MongoDB也是CP阵营的一员。

ACID（原子性、一致性、隔离性、持久性。）和 BASE 代表了两种截然相反的设计哲学，分区一致性 - 可用性分布图谱的两极。ACID 注重一致性，是数据库的传统设计思路，也有很多优点。

中文博大精深，此处英文也有异曲同工之妙💫。

ACID和BASE除了设计哲学上是大路朝天各走一边，而且在英文原意上也是冤家路窄，前者是“酸”，后者是“碱”。

出现较晚的 BASE 硬凑的感觉更明显，它是“Basically Available, Soft state, Eventually consistent（基本可用、软状态、最终一致性）”的首字母缩写。其中的软状态和最终一致性这两种技巧擅于对付存在分区的场合，并因此提高了可用性。

当然，从数学逻辑的层面上讲，只有强一致性和不一致。最终一致性等于没有一致性，或者不保证强一致，属于一致性模型的范畴。BASE的目的是弥合分区场合下A和C之间的裂痕——虽然墙体已然出现了缝隙，但表面上仍然是粉饰的平平整整。

综上，ACID在一致性的路上一往无前，BASE则试图对可用性进行改良。CAP是帽子，BASE更像是帽檐上的挂穗🎓。

CAP 与 ACID 的关系更复杂一些，也因此引起更多误解。其中一个原因是 ACID 的 C 和 A 字母所代表的概念不同于 CAP 的 C 和 A。

译注：

记得我们在学习ACID的概念时，总是会讲银行汇取款的故事来讲原子操作至关重要，所以金融系统几乎完全使用 ACID 数据库。在金钱方面，肯定有一方无法容忍不一致的发生。

总的来说，OLTP搭ACID，OLAP搭BASE已经尽善尽美了，然而，新的体系结构HTAP还是出现了，混合事务分析处理野心勃勃地要打破事务处理和分析之间的“墙”🔨————结合前面的分析来说，理论上是做不到的，只能在API层面（对用户来说透明）进行融合，底层则是缝合怪。

CAP 理论的经典解释，是忽略网络延迟的，但在实际中延迟和分区紧密相关。网络阻塞时，依靠多次尝试通信的方法来达到一致性，比如 Paxos 算法或者两阶段事务提交，但这仅是拖延了决策的时间，系统最终要做一个决定。无限期地尝试下去，本身就是选择一致性牺牲可用性的表现。

CAP 理论经常在不同方面被人误解，对于可用性和一致性的作用范围的误解尤为严重，如果用户根本获取不到服务，那么其实谈不上 C 和 A 之间做取舍。

译注：

所谓“存地失人，人地皆失；存人失地，人地皆得”。

实践中，大部分团体认为（位于单一地点的）数据中心内部是没有分区的，因此在单一数据中心之内可以选择 CA；CAP 理论出现之前，系统都默认这样的设计思路，包括传统数据库在内。然而就算可能性极低，单数据中心完全有可能出现分区的情况，一旦出现就会动摇以 CA 为取向的设计基础。最后，考虑到跨区域时出现的高延迟，在数据一致性上让步来换取更好性能的做法相对比较常见。

当代 CAP 实践**应将目标定为针对具体的应用，在合理范围内最大化数据一致性和可用性的“合力”。**这样的思路延伸为如何规划分区期间的操作和分区之后的恢复，从而启发设计师加深对 CAP 的认识，突破过去由于 CAP 理论的表述而产生的思维局限。

后语

CAP并不是牺牲三要素其一的挡箭牌，而是启发设计者就C&A进行更加高效合理的架构规约，没有万能的架构，只有最合适的场景。

---

后面我会另文探讨一下HTAP产品以及新生的大数据软件是真的结束了这场纷争🥂，亦或是新瓶装旧酒🍷？

欢迎访问我的博客~