分布式系统那些事-CAP和BASE理论

CAP理论

定义

CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性（Consistence）

  每次读取到的数据都是最近一次写的数据，等同于所有节点访问同一份最新的数据副本。

• 可用性（Availability）

  每次请求都能在一定时间内获取到非错的响应——但是不保证获取的数据为最新数据。

• 分区容错性（Partition tolerance）

  分布式系统在遇到某节点或网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务。除了整个网络的故障外，其他的故障都不能导致整个系统无法正确响应。

注：
网络分区（Network Partition） 并非节点 Crash，更侧重于 “节点双方一时联系不上对方” 的一个状态。造成网络分区的原因可能是网络不可达，也可能是GC的Stop The World阻塞太久，也可能是 CPU 彪到一个死循环上，更多原因参考 https://github.com/aphyr/partitions-post

CAP之间的取舍

• 放弃分区容错性

  为了避免分区容错性问题的发生，一种做法是将所有的数据（与事务相关的）都放在一台机器上。虽然无法100%保证系统不会出错，但不会碰到由分区带来的负面效果。但是，系统从分布式系统退化为单机系统，失去了可扩展性，严重影响系统规模。

• 放弃可用性

  相对于放弃“分区容错性“来说，其反面就是放弃可用性。一旦遇到分区容错故障，那么受到影响的服务需要等待一定的时间，因此在等待期间系统无法对外提供服务。

• 放弃一致性

  要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。当然，这里所说的放弃一致性，并不是完全放弃数据一致性，而是放弃数据的强一致性，而保留数据的最终一致性。

下图展示了围绕CA、AP和CP构建的技术：

CAP定理并不意味着所有系统的设计都必须抛弃三个要素中的一个。三者可以在一定程度上衡量，并不是非黑即白，例如可用性从0%到100%有不同等级。

BASE理论

定义

BASE理论是指，基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual consistency），是基于CAP定理演化而来，是对CAP中一致性和可用性权衡的结果。

• 基本可用（Basically Available）

  基本可用，指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。比如为了应对访问量激增，部分用户可能会被引导到降级页面，服务层可能也只提供降级服务。

• 柔性状态（Soft State）

  允许系统存在中间状态，二中间状态不会影响系统整体可用性。如MySQL主从复制延迟就是柔性状态的提现。

• 最终一致性（Eventual consistency）

  系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

ACID和BASE的区别与联系

ACID和BASE代表了两种截然相反的设计哲学。ACID是传统数据库常用的设计理念，追求强一致性模型。BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此ACID和BASE又会结合使用。

参考

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

[2] 分布式系统之CAP理论

[3] 分布式系统理论基础 - CAP

[4] CAP理论十二年回顾："规则"变了