CAP原则（CAP定理）、BASE理论

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

CAP原则是NOSQL数据库的基⽯。

分布式系统的CAP理论：理论⾸先把分布式系统中的三个特性进⾏了如下归纳：
⼀致性（C）：在分布式系统中的所有数据备份，在同⼀时刻是否同样的值。

（等同于所有节点访问同⼀份最新的数据副本）
可⽤性（A）：在集群中⼀部分节点故障后，集群整体是否还能响应客户端的读写请求。

（对数据更新具备⾼可⽤性）
分区容忍性（P）：以实际效果⽽⾔，分区相当于对通信的时限要求。

系统如果不能在时限内达成数据⼀致性，就意味着发⽣了分区的情况，必须就当前操作在C和A之间做出选择。

⼀致性与可⽤性的决择
CAP理论就是说在分布式存储系统中，最多只能实现上⾯的两点。

⽽由于当前的⽹络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。

所以我们只能在⼀致性和可⽤性之间进⾏权衡，没有NoSQL系统能同时保证这三点。

对于web2.0⽹站来说，关系数据库的很多主要特性却往往⽆⽤武之地
1. 数据库事务⼀致性需求
很多web实时系统并不要求严格的数据库事务，对读⼀致性的要求很低，有些场合对写⼀致性要求并不⾼。

允许实现最终⼀致性。

2. 数据库的写实时性和读实时性需求
对关系数据库来说，插⼊⼀条数据之后⽴刻查询，是肯定可以读出来这条数据的，但是对于很多web应⽤来说，并不要求这么⾼的实时性，⽐⽅说发⼀条消息之后，过⼏秒乃⾄⼗⼏秒之后，我的订阅者才看到这条动态是完全可以接受的。

3. 对复杂的SQL查询，特别是多表关联查询的需求
任何⼤数据量的web系统，都⾮常忌讳多个⼤表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的⽹站，从需求以及产品设计⾓度，就避免了这种情况的产⽣。

往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极⼤的弱化了。

取舍策略
CAP三个特性只能满⾜其中两个，那么取舍的策略就共有三种：
CA without P：如果不要求P（不允许分区），则C（强⼀致性）和A（可⽤性）是可以保证的。

但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署⼦节点，这是违背分布式系统设计的初衷的。

传统的关系型数据库RDBMS：Oracle、MySQL就是CA。

CP without A：如果不要求A（可⽤），相当于每个请求都需要在服务器之间保持强⼀致，⽽P（分区）会导致同步时间⽆限延长(也就是等待数据同步完才能正常访问服务)，⼀旦发⽣⽹络故障或者消息丢失等情况，就要牺牲⽤户的体验，等待所有数据全部⼀致了之后再让⽤户访问系统。

设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。

对于这些分布式数据库来说，数据的⼀致性是最基本的要求，因为如果连这个标准都达不到，那么直接采⽤关系型数据库就好，没必要再浪费资源来部署分布式数据库。

AP wihtout C：要⾼可⽤并允许分区，则需放弃⼀致性。

⼀旦分区发⽣，节点之间可能会失去联系，为了⾼可⽤，每个节点只能⽤本地数据提供服务，⽽这样会导致全局数据的不⼀致性。

典型的应⽤就如某⽶的抢购⼿机场景，可能前⼏秒你浏览商品的时候页⾯提⽰是有库存的，当你选择完商品准备下单的时候，系统提⽰你下单失败，商品已售完。

这其实就是先在 A（可⽤性）⽅⾯保证系统可以正常的服务，然后在数据的⼀致性⽅⾯做了些牺牲，虽然多少会影响⼀些⽤户体验，但也不⾄于造成⽤户购物流程的严重阻塞。

BASE理论
BASE是Basically Available（基本可⽤）、Soft state（软状态）和Eventually consistent（最终⼀致性）三个短语的简写，BASE是对CAP 中⼀致性和可⽤性权衡的结果，其来源于对⼤规模互联⽹系统分布式实践的结论，是基于CAP定理逐步演化⽽来的，其核⼼思想是即使⽆法做到强⼀致性（Strong consistency），但每个应⽤都可以根据⾃⾝的业务特点，采⽤适当的⽅式来使系统达到最终⼀致性（Eventual consistency）。

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

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

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

功能上的损失：正常情况下，在⼀个电⼦商务⽹站上进⾏购物，消费者⼏乎能够顺利地完成每⼀笔订单，但是在⼀些节⽇⼤促购物⾼峰的时候，由于消费者的购物⾏为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到⼀个降级页⾯。

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

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

因此，最终⼀致性的本质是需要系统保证最终数据能够达到⼀致，⽽不需要实时保证系统数据的强⼀致性
亚马逊⾸席技术官Werner Vogels在于2008年发表的⼀篇⽂章中对最终⼀致性进⾏了⾮常详细的介绍。

他认为最终⼀致性时⼀种特殊的弱⼀致性：系统能够保证在没有其他新的更新操作的情况下，数据最终⼀定能够达到⼀致的状态，因此所有客户端对系统的数据访问都能够胡渠道最新的值。

同时，在没有发⽣故障的前提下，数据达到⼀致状态的时间延迟，取决于⽹络延迟，系统负载和数据复制⽅案设计等因素。

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

因果⼀致性：
因果⼀致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进⾏更新操作的话，务必基于进程A更新后的最新值，即不能发⽣丢失更新情况。

与此同时，与进程A ⽆因果关系的进程C的数据访问则没有这样的限制。

读⼰之所写：
读⼰之所写是指，进程A更新⼀个数据项之后，它⾃⼰总是能够访问到更新过的最新值，⽽不会看到旧值。

也就是说，对于单个数据获取者⽽⾔，其读取到的数据⼀定不会⽐⾃⼰上次写⼊的值旧。

因此，读⼰之所写也可以看作是⼀种特殊的因果⼀致性。

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

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

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

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

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

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

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

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

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

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

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

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

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

与NoSQL的关系
传统的关系型数据库在功能⽀持上通常很宽泛，从简单的键值查询，到复杂的多表联合查询再到事务机制的⽀持。

⽽与之不同的
是，NoSQL系统通常注重性能和扩展性，⽽⾮事务机制（事务就是强⼀致性的体现）[2] 。

传统的SQL数据库的事务通常都是⽀持ACID的强事务机制。

A代表原⼦性，即在事务中执⾏多个操作是原⼦性的，要么事务中的操作全部执⾏，要么⼀个都不执⾏;C代表⼀致性，即保证进⾏事务的过程中整个数据加的状态是⼀致的，不会出现数据花掉的情况;I代表隔离性，即两个事务不会相互影响，覆盖彼此数据等;D表⽰持久化，即事务⼀量完成，那么数据应该是被写到安全的，持久化存储的设备上（⽐如磁盘）。

NoSQL系统仅提供对⾏级别的原⼦性保证，也就是说同时对同⼀个Key下的数据进⾏的两个操作，在实际执⾏的时候是会串⾏的执⾏，保证了每⼀个Key-Value对不会被破坏。

CAP的是什么关系
It states, that though its desirable to have Consistency, High-Availability and Partition-tolerance in every system, unfortunately no system can achieve all three at the same time.
在分布式系统的设计中，没有⼀种设计可以同时满⾜⼀致性，可⽤性，分区容错性 3个特性
注意：不要将弱⼀致性，最终⼀致性放到CAP理论⾥混为⼀谈（混淆概念的坑真多）
弱⼀致性，最终⼀致性你可以认为和CAP的C⼀点关系也没有，因为CAP的C是更新操作完成后，任何节点看到的数据完全⼀致, 弱⼀致性。

最终⼀致性本⾝和CAP的C⼀致性是违背的，所以你可以看到那些谎称⾃⼰系统同时具备CAP 3个特性是多么的可笑，可能国内更多的场景是：⼀个开放⼈员⼀旦⾛上讲台演讲，就⽴马转变为了营销⼈员，连最基本的理念也不要了。

这⾥有⼀篇标题很⼤的⽂章，实际上本⽂的changed更多的是在思考⽅式上，⽽本⾝CAP理论是没有changed的
为什么会是这样
我们来看⼀个简单的问题, ⼀个DB服务搭建在两个机房（北京,⼴州)，两个DB实例同时提供写⼊和读取
1. 假设DB的更新操作是同时写北京和⼴州的DB都成功才返回成功
在没有出现⽹络故障的时候，满⾜CA原则，C 即我的任何⼀个写⼊，更新操作成功并返回客户端完成后,分布式的所有节点在同⼀时间的数据完全⼀致， A 即我的读写操作都能够成功，但是当出现⽹络故障时，我不能同时保证CA，即P条件⽆法满⾜
2. 假设DB的更新操作是只写本地机房成功就返回，通过binlog/oplog回放⽅式同步⾄侧边机房
这种操作保证了在出现⽹络故障时,双边机房都是可以提供服务的，且读写操作都能成功，意味着他满⾜了AP ，但是它不满⾜C，因为更新操作返回成功后，双边机房的DB看到的数据会存在短暂不⼀致，且在⽹络故障时，不⼀致的时间差会很⼤（仅能保证最终⼀致性）
3. 假设DB的更新操作是同时写北京和⼴州的DB都成功才返回成功且⽹络故障时提供降级服务
降级服务，如停⽌写⼊，只提供读取功能，这样能保证数据是⼀致的，且⽹络故障时能提供服务，满⾜CP原则，但是他⽆法满⾜可⽤性原则
选择权衡
通过上⾯的例⼦，我们得知，我们永远⽆法同时得到CAP这3个特性，那么我们怎么来权衡选择呢？
选择的关键点取决于业务场景
对于⼤多数互联⽹应⽤来说（如⽹易门户），因为机器数量庞⼤，部署节点分散，⽹络故障是常态，可⽤性是必须需要保证的，所以只有设置⼀致性来保证服务的AP，通常常见的⾼可⽤服务吹嘘5个9 6个9服务SLA稳定性就本都是放弃C选择AP
对于需要确保强⼀致性的场景，如银⾏，通常会权衡CA和CP模型，CA模型⽹络故障时完全不可⽤，CP模型具备部分可⽤性，实际的选择需要通过业务场景来权衡（并不是所有情况CP都好于CA，只能查看信息不能更新信息有时候从产品层⾯还不如直接拒绝服务）
延伸
BASE(Basically Available, Soft State, Eventual Consistency 基本可⽤、软状态、最终⼀致性) 对CAP AP理论的延伸, Redis等众多系统构建与这个理论之上
ACID 传统数据库常⽤的设计理念, ACID和BASE代表了两种截然相反的设计哲学，分处⼀致性-可⽤性分布图谱的两极。

分布式系统的典型应⽤
分布式系统是⼀个⾮常⼴泛的概念，它最终要落实到解决实际问题上，不同的问题有不同的⽅法和架构。

所有的开源软件都是以某个应⽤场景出现，⽽纯粹以“分布式”概念进⾏划分的⽐较少见。

但如果以算法划分，到能分出⼏类：
1.以Leader选举为主的⼀类算法，⽐如paxos、viewstamp，就是现在zookeeper、Chuby等⼯具的主体
2.以分布式事务为主的⼀类主要是⼆段提交，这些分布式数据库管理器及数据库都⽀持
3.以若⼀致性为主的，主要代表是Cassandra的W、R、N可调节的⼀致性
4.以租赁机制为主的，主要是⼀些分布式锁的概念，⽬前还没有看到纯粹“分布式”锁的实现
5.以失败探测为主的，主要是Gossip和phi失败探测算法，当然也包括简单的⼼跳
6.以弱⼀致性、因果⼀致性、顺序⼀致性为主的，开源尚不多，但⼤都应⽤在Linkedin、Twitter、Facebook等公司内部
7当然以异步解耦为主的，还有各类Queue。