CAP 定理和 BASE理论 (了解分布式事务理论模型)

分布式事务理论模型

一.CAP定理

首先了解下CAP 概念 :

一致性 (C:Consistency) : 数据在多个副本中要保持强一致性,[写操作之后的读操作,必须返回该值].

可用性 (A:Availability) : 系统对外提供服务必须一直处于可用状态,在任何故障下,客户端都能在合理的
时间内获得服务器的非错误响应. [收到请求服务器就会给出回应].

分区容错性 (P:Partition Tolerance) : 网络分区之间的通信可能失败的情况下,系统还能继续运行.

(概念图如下:)

         又叫布鲁尔定理.简单来讲指分布式系统中不可能同时满足 CAP 三个基本需求,最多同时满足两个.
         要么满足CP , 要么满足AP ,原因是网络通信并不是绝对可靠的,这点大家应该很清楚,比如网络延时,网络异常等都会导致系统故障.在分布式系统中就算网络故障也需要保证系统能够正常对外提供服务,所以P是必然存在的,也就是必须得满足分区容错性.

一句话概括 “三者不可兼得” ,

CP : 每个请求都需要在服务器之间保持强一致,即服务之间数据要同步且是强一致.而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。这样就放弃了高可用性,来保证强一致性, 2PC和3PC都采用这种方案. 可能导致的问题是用户完成一个操作等待的时间较长.[比如:ZooKeeper / Redis / MongoDB / HBase]

AP : 放弃了强一致性 ,实现最终的一致.这是许多互联网公司解决分布式数据一致性问题的主要选择. 如果发生了分区(节点之间通信故障),无法与未出现通信故障的服务同步数据,这时就只能使用本地的旧数据提供服务,这样就是失去了一致性,但是我依然用旧的数据提供服务给调用方. 比如:小米手机抢购时,浏览时还显示有,等你下单时就显示无了.

CA : 那就不存在分区,放弃了系统的扩展性,违背了分布式的初衷, 比如:传统的单点关系型数据库RDBMS：Oracle、MySQL,如果集群就得考虑P. (当网络变的百分之百的可靠时,定理自破)

这里在举个形象的例子 :

      有个宝宝非常喜欢看ipad,妈妈就觉得这样对宝宝的眼睛不好,于是规定宝宝一天只能看一次,想看的时候来找妈妈要.
这样似乎是解决这个问题,但是如果妈妈去上班了,宝宝就看不了了.这里就好比服务因为某些原因无法对外及时提供服务.可用性就降低了.也就是出现了单点故障,为了增加可用性妈妈把这个权利也交给了爸爸,宝宝也可以找爸爸要ipad.这样妈妈上班了还有爸爸呢.(消除单点故障,增加冗余),.
      这样貌似也解决了这样的问题.可是宝宝比较机灵,早上找爸爸看,晚上找妈妈看,(出现了数据一致性降低的问题),于是宝宝找爸爸看ipad时会打个电话询问下妈妈宝宝今天看了没(节点之间同步数据,增大了一致性但是同步数据是需要消耗时间和资源成本的),这样看上去似乎也没毛病,但如果妈妈比较忙或者手机没电一时间联系不到妈妈,这该如何做出决策? (分区发生) .
       这里分两种情况 : 如果爸爸给了宝宝(也就是提供了服务,增加了可用性,但是降低了一致性),不给的话相反.都是以爸爸自身本地的数据来考量是否给宝宝. 还有一种情况(实现最终一致性),给宝宝看了,但是爸爸还是不放心,于是每隔一段时间就联系妈妈(定时扫描) , 不久就联系上了,妈妈说宝宝看过了,不能看了.于是爸爸收回了ipad.没有造成很大的影响.
       拓展 : [在多节点高可用的情况下,出现单机故障,"脑裂"就需要 “选举”,涉及到共识算法,这里就不做过多的阐述]

---

二.BASE理论

        BASE 理论是由于 CAP 中的一致性和可用性不可兼得而衍生出来的一种新的思想. 是由eBay架构师提出的,其来源于对大规模互联网分布式系统实践的总结，是基于 CAP 定理逐步演化而来. BASE 理论的核心思想是通过牺牲数据的强一致性来获得高可用性,但每个系统都可以根据自身业务特点，用适当的方式来使系统打到最终一致性。它有如下三个特性 :

    ○ Basically Available (基本可用) :
分布式系统在出现故障时,允许损失一部分功能的可用性,保证核心功能的可用性.比如秒杀抢购环节,需要保证购物系统的稳定,需要关闭一些相对来说不紧要的服务。

   ○ Soft State (软状态) :
允许系统中的数据存在中间状态,这个状态不影响系统的可用性,也就是允许系统中不同节点的数据副本之间的同步存在延时.相反硬状态节点数据副本一致.

   ○ Eventually Consistent (最终一致性) :
中间状态的数据在经过一段时间之后,会达到一个最终的数据一一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

BASE 理论并没有要求数据的强一致性,而是允许数据在一段时间内是不一致的,但是数据最终会在某个时间点 实现一致。

最终一致性在实际工程实践中又分为 5 种 :

①因果一致性（Causal consistency）:
    如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。简单点就是如果进程A和进程B说了A更新了，那么B必须立刻拿到最新的数据,但是如果C读就不需要立刻一致。

②读写一致性 (Read your writes) :
    节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值.

③单调读一致性（Monotonic read consistency）:
    一个进程看到了某一个值，那么之后的读取不能看到那个值之前的值,举个例子: 小明从窗户外面看到
屋里是晓红穿了短袖,进屋后也必须是穿短袖. 换个说法: 如果一个节点从系统中读取出一个数据项的某
个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。

④单调写一致性 (Monotonic write consistency) :
    系统要能够保证来自同一个节点的写操作被顺序的执行.先到先得.

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

事实上 , 不只是分布式系统使用最终一致性，关系型数据库在某些功能上，也是使用最终一致性的。比如备份，数据库的复制过程是需要时间的，这个复制过程中，业务读取到的值就是旧的。当然，最终还是达成了数据一致性。
BASE 理论面向的是大型高可用、可扩展的分布式系统。与传统 ACID 强一致性特性相反，BASE提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内的不一致，但是最终达到一致状态。同时，在实际分布式场景中，不同业务对数据的一致性要求不一样。因此在设计中，ACID 和 BASE理论往往又会结合使用。

---

了解CAP的扩展 PACELC 理论 => PACELC

在一个存在网络分区（p） 的分布式计算机系统中，我们必须在可用性(A)和一致性（C）中取舍，而且(E)，即使系统没有存在分区，也需要在延时(L)和一致性©中进行取舍。
感慨： 就算网络非常靠谱不会断,但是如果慢的话,往往都会加缓存, 缓存就是快嘛,减少延时,这里就又出现了,缓存的数据一致性问题, 所以即使没存在分区,也要在一致性和延时中取舍.（如果等到有一天家用计算机能达到超级计算机的能力，那这些问题也会被掩盖）。

今天的分享就到这啦，后面还会不断的更新哦！

参考 [微服务原理与实战]–谭峰