CAP 定理

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

  • Consistency

  • Availability

  • Partition tolerance

它们的第一个字母分别是 C、A、P。

Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。

输入图片说明

这给人的感觉就是鱼和熊掌不可兼得，对于追求完美的程序员而言有些难以接受。

那么，为什么三者不可能同时做到呢？

Partition tolerance

先看 Partition tolerance，中文叫做”分区容错”。

大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。

一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。

CAP 定理告诉我们，剩下的 C 和 A 无法同时做到。

网络通讯中一定要考虑通讯失败的情况。这就是我们一般必须考虑 P 的问题。

可能有些小伙伴要问了，我能不能放弃分区容错呢？

你可真是一个小机灵鬼，放弃了分区，你的系统也就不是分布式系统了。

例子

输入图片说明

假设 G1、G2 是2台服务器，一台在国内，另一台在国外。那么二者就可能出现网络通讯失败的情况。

永远记住网络开发第一定律：网络通讯随时可能失败。

Consistency

Consistency 中文叫做”一致性”。意思是，写操作之后的读操作，必须返回该值。

ps: 这个和数据库中的 ACID 的 c 应该是类似的。

例子

个人感觉这里使用数据库的主从可能更好理解一点，因为大家都有类似的开发经验。

假设主库是 G1，从库是 G2。

用户首先修改主库 G1 把记录 v0 改成了 v1，此时如果用户读取 G1，返回的是 v1，那么是没有问题的。

注意从库 G2 的同步是有延时的，甚至可能失败。

所以如果有用户读取了 G2，可能获取到的就是 v0，这里就违反了一致性。

Availability

Availability 中文叫做”可用性”，意思是只要收到用户的请求，服务器就必须给出回应。

用户可以选择向 G1 或 G2 发起读操作。

不管是哪台服务器，只要收到请求，就必须告诉用户，到底是 v0 还是 v1，否则就不满足可用性。

这个就是我们常说的考可用，系统可用性 99.9999% 之类的。

矛盾点在哪里？

我相信聪明的你已经发现其中的矛盾之处了。

一致性（C）和可用性（A），为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分区容错（P））。

就是这么简单粗暴。

权衡得失

通过CAP理论，我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要舍弃哪个呢？

输入图片说明

CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。

CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。

AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

个人理解

一致性的追求一般是在金融等涉及到钱的领域，要求比较严格。

比如主从数据库的情况下，我们可以牺牲一部分可用性，比如强制读取主库，保证金额等信息是最新的。

当用户对于一致性要求没有那么高时，必须页面的一些信息展现等，用户获取到的不是最新的也没有太大关系，用户关心的更多的是服务可用性。

架构没有最优，只有 trade-off。

BASE 理论

CAP 理论和 BASE 理论被称之为分布式理论界的双子星（老马瞎编的）。

什么是 BASE 理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的。

其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

接下来我们着重对BASE中的三要素进行详细讲解。

Basically Available（基本可用）

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子。

响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。

功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

Soft state（软状态）

弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据听不的过程存在延时。

Eventually consistent（最终一致性）

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。

因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

亚马逊首席技术官Werner Vogels在于2008年发表的一篇文章中对最终一致性进行了非常详细的介绍。

他认为最终一致性时一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够胡渠道最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟，系统负载和数据复制方案设计等因素。

在实际工程实践中，最终一致性存在以下五类主要变种。

（1）因果一致性：

因果一致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最新值，即不能发生丢失更新情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。

（2）读己之所写：

读己之所写是指，进程A更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者而言，其读取到的数据一定不会比自己上次写入的值旧。因此，读己之所写也可以看作是一种特殊的因果一致性。

（3）会话一致性：

会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现“读己之所写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

（4）单调读一致性：

单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

（5）单调写一致性：

单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序地执行。

以上就是最终一致性的五类常见的变种，在时间系统实践中，可以将其中的若干个变种互相结合起来，以构建一个具有最终一致性的分布式系统。

事实上，可以将其中的若干个变种相互结合起来，以构建一个具有最终一致性特性的分布式系统。

事实上，最终一致性并不是只有那些大型分布式系统才设计的特性，许多现代的关系型数据库都采用了最终一致性模型。

在现代关系型数据库中，大多都会采用同步和异步方式来实现主备数据复制技术。

在同步方式中，数据的复制通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致。

而在异步方式中，备库的更新往往存在延时，这取决于事务日志在主备数据库之间传输的时间长短，如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上，那么显然，从备库中读取的的数据将是旧的，因此就出现了不一致的情况。

当然，无论是采用多次重试还是认为数据订正，关系型数据库还是能搞保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性使相反的，它完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在一起使用。

参考资料

CAP 定理的含义

[分布式]：分布式系统的CAP理论

CAP原则(CAP定理)、BASE理论