CAP原则BASE理论

Posted 2020-10-17 明-学以致用

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了CAP原则BASE理论相关的知识，希望对你有一定的参考价值。

CAP原则、BASE理论

2017-12-15

1 CAP原则
1.1 CAP原则是什么
1.2 CAP为何三者不可得兼
1.3 一致性与可用性的决择
2 BASE理论
2.1 BASE理论是什么
2.2 ACID和BASE的区别与联系
2.3 最终一致性五钟变种
3 分布式系统的典型应用
 参考

计算机系统从集中式向分布式的变革，随着包括分布式网络、分布式事务和分布式数据一致性等在内的一系列问题与挑战，同时也催生了一大批诸如ACID、CAP和BASE等经典理论的快速发展。

1 CAP原则

1.1 CAP原则是什么

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

1.2 CAP为何三者不可得兼

举例：我们来看一个简单的问题, 一个DB服务搭建在两个机房（北京,广州)，两个DB实例同时提供写入和读取

假设DB的更新操作返回成功条件：是同时写北京和广州的DB都成功
- 在没有出现网络故障的时候，满足CA原则，C 即我的任何一个写入，更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致， A 即我的读写操作都能够成功，但是当出现网络故障时，我不能同时保证CA，即P条件无法满足
假设DB的更新操作返回成功条件：是只写本地机房成功，通过binlog/oplog回放方式同步至侧边机房
- 这种操作保证了在出现网络故障时,双边机房都是可以提供服务的，且读写操作都能成功，意味着他满足了AP ，但是它不满足C，因为更新操作返回成功后，双边机房的DB看到的数据会存在短暂不一致，且在网络故障时，不一致的时间差会很大（仅能保证最终一致性）
假设DB的更新操作返回成功条件：是同时写北京和广州的DB都成功才返回成功且网络故障时提供降级服务
- 降级服务，如停止写入，只提供读取功能，这样能保证数据是一致的，且网络故障时能提供服务，满足CP原则，但是他无法满足可用性原则

1.3 一致性与可用性的决择

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡。
对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地

数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求并不高。允许实现最终一致性。
数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

2 BASE理论

2.1 BASE理论是什么

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。

BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来我们着重对BASE中的三要素进行详细讲解。

基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。
注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子：
- 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
- 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
弱状态：也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
- 亚马逊首席技术官Werner Vogels在于2008年发表的一篇文章中对最终一致性进行了非常详细的介绍。他认为最终一致性时一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够获取到最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟，系统负载和数据复制方案设计等因素。

2.2 ACID和BASE的区别与联系

BASE是对CAP AP理论的延伸, Redis等众多系统构建与这个理论之上。

ACID是传统数据库常用的设计理念，追求强一致性模型。BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。ACID和BASE代表了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此ACID和BASE又会结合使用。

2.3 最终一致性五钟变种

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

因果一致性：如果Process A通知Process B它已经更新了数据，那么Process B的后续读取操作务必基于A写入的最新值。与此同时，与Process A无因果关系的Process C的数据访问则没有这样的限制。
读你所写一致性：如果Process A写入了最新的值，那么 Process A的后续操作都会读取到最新值。但是其它用户可能要过一会才可以看到。
会话一致性：一次会话内一旦读到某个值，不会读到更旧的值。
单调读一致性：一个用户一旦读到某个值，不会读到比这个值更旧的值，其他用户不一定。
单调写一致性：一个系统需要能够保证来自同一个进程的写操作被顺序地执行

其中最重要的变体是第二条：读你所写一致性。特别适用于数据的更新同步，用户的修改马上对自己可见，但是其他用户可以看到他老的版本。Facebook的数据同步就是采用这种原则。