CAP定理

CAP定理      

1、CAP理论原理

一、CAP理论介绍

2000年7月，加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜测。2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证实了CAP。以后，CAP理论正式成为分布式计算领域的公认定理。

CAP理论:

一个分布式系统最多只能同时知足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

二、CAP理论解释

C:Consistency一致性

一致性指“all nodes see the same data at the same time”，即更新操做成功并返回客户端完成后，全部节点在同一时间的数据彻底一致。

A: Availability可用性

可用性指“Reads and writes always succeed”，即服务一直可用，并且是正常响应时间。

P: Partition tolerance分区容错性

分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然可以对外提供知足一致性和可用性的服务。

2、CAP使用权衡

一、保留CA，放弃P

若是想避免分区容错性问题的发生，一种作法是将全部的数据（与事务相关的）都放在一台机器上。虽然没法100%保证系统不会出错，但不会碰到由分区带来的负面效果。固然这个选择会严重的影响系统的扩展性。

做为一个分布式系统，放弃P，即至关于放弃了分布式，一旦并发性很高，单机服务根本不能承受压力。

像不少银行服务，确确实实就是舍弃了P，只用单台小型机+ORACLE保证服务可用性。

二、保留CP，放弃A

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

做为分布式系统，有分区服务发生问题颇有可能，若是由于某些服务不能用，致使整个服务都不能用，这个根本不是好的分布式系统。

三、保留AP，舍弃C

这里所说的放弃一致性，并非彻底放弃数据一致性，而是放弃数据的强一致性。即放弃了同一时刻的数据一致性，而保留数据的最终一致性。

以网络购物为例，对只剩下一件库存的商品，若是同时接受到了两份订单，那么较晚的订单将被告知商品告罄。

一般状况下，不少分布式服务系统都是采用该方案，保证可用性性，分布式服务，由于某些分区服务发生问题，先容忍，最终经过一些折中的方法达到最终数据一致性。

 
 
 

---

---

 

CAP理论是分布式数据库中很重要的理论基础。CAP即Consistnecy 一致性，Avaliability 可用性，Partition-tolerance分区容忍性 的缩写。在分布式系统中，三者不可兼得，只能获得其中之二。因此就有了三个分类：CA数据库，CP数据库，AP数据库。

 

CA数据库不考虑分区容忍性，对应现实中是数据库就是普通的关系型数据库RDBMS。

CP数据库考虑的是一致性和分区容忍性，这种数据库对分布式系统内的通讯要求比较高，由于要保持数据的一致性，须要作大量的交互。

AP数据库考虑的是实用性和分区容忍性，即外部访问数据，能够更快的获得回应。这时候，数据的一致性就可能得不到知足。好比一个数据，可能外部一个进程在改写这个数据，同时另外一个进程在读这个数据，此时，数据显现是不一致的。可是有一点，就是数据库会知足一个最终一致性的概念，即过程多是不一致的，可是到某一个终点，数据就会一致起来。

 著名 CAP理论：在分布式数据库应用中，任何分布式  系统  只可同时知足CAP其中两点，没法三者兼顾。  

Consistency(一致性), 数据一致更新，全部数据变更都是同步的。  

Availability(可用性), 好的响应性能。

Partition tolerance(分区容错性) 可靠性。    

CA 系统是要求高可用用而且实时一致性。单点数据库是符合这种架构的，例如超市收银系统，  图书  管理系统。      

       

AP 知足可用性，分区容忍性的系统，一般可能对一致性要求低一些。例如博客系统。

CP 系统是要求知足一致性，分区容忍性，一般性能不是特别高。例如火车售票系统。         

忠告：架构师不要将精力浪费在如何设计能知足三者的完美分布式系统，而是应该进行取舍。           

           

三、 最终一致性的系统是符合AP理论架构，对可用和分区容错要求较高，对数据实时一致要求较低。网络论坛或weibo的系统架构都符合最终一致性的应用。 

四、数据库中间件服务时是对分布式数据库的一个管理系统，其中负载均衡和扩展性相对来讲是它的核心所在。  

 
 
 
 

---

---

 

分布式的优势是大大的，最明显的就是能够同时处理不少事情，能够同时响应不少请求。

分布式的缺点也是大大的。

机器之间须要花费很多时间精力来沟通，这就是分布式的缺点。

沟通到机器认识在一个水平，数据状态一致,这叫同步。
沟通的时候有部分消息没有正确传给对方，这叫信号丢失。
沟通的时候，发现机器A和机器B思路彻底不同，出现网络中断分离，这就等同于俩数据中心。

 
 
 

---

---

 

1.ACID  

    ACID，是指在数据库管理系统（DBMS）中，事务(transaction)所具备的四个特性：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation，又称独立性)、持久性(Durability)。

    在数据库系统中，一个事务是指：由一系列数据库操做组成的一个完整的逻辑过程。例如银行转账，从原帐户扣除金额，以及向目标帐户添加金额，这两个数据库操做的总和，构成一个完整的逻辑过程，不可拆分。这个过程被称为一个事务，具备ACID特性。

1)原子性(Atomicity)

    一个事务(transaction)中的全部操做，要么所有完成，要么所有不完成，不会结束在中间某个环节。事务在执行过程当中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务历来没有执行过同样。

2)一致性(Consistency)

    事务的一致性指的是在一个事务执行以前和执行以后数据库都必须处于一致性状态。若是事务成功地完成，那么系统中全部变化将正确地应用，系统处于有效状态。若是在事务中出现错误，那么系统中的全部变化将自动地回滚，系统返回到原始状态。

3)隔离性(Isolation)

    指的是在并发环境中，当不一样的事务同时操纵相同的数据时，每一个事务都有各自的完整数据空间。由并发事务所作的修改必须与任何其余并发事务所作的修改隔离。事务查看数据更新时，数据所处的状态要么是另外一事务修改它以前的状态，要么是另外一事务修改它以后的状态，事务不会查看到中间状态的数据。

4)持久性(Durability)

    指的是只要事务成功结束，它对数据库所作的更新就必须永久保存下来。即便发生系统崩溃，从新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

    事务的（ACID）特性是由关系数据库管理系统（RDBMS，数据库系统）来实现的。 数据库管理系统采用日志来保证事务的原子性、一致性和持久性。日志记录了事务对数据库所作的更新，若是某个事务在执行过程当中发生错误，就能够根据日志，撤销事务对数据库已作的更新，使数据库退回到执行事务前的初始状态。

2.CAP  

         一致性(Consistency)、可用性(Availability)和分区容忍性(Partitiontolerance)。CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。   这是   Brewer   教授于   2000   年提出的，后人也论证了   CAP   理论的正确性。  

1)一致性（Consistency） ：( 一样数据在分布式系统中全部地方都是被复制成相同。)  

    对于分布式的存储系统，一个数据每每会存在多份。简单的说，一致性会让客户对数据的修改操做（增/删/改），要么在全部的数据副本（replica）所有成功，要么所有失败。即，修改操做对于一份数据的全部副本（整个系统）而言，是原子（atomic）的操做。  

    若是一个存储系统能够保证一致性，那么则客户读写的数据彻底能够保证是最新的。不会发生两个不一样的客户端在不一样的存储节点中读取到不一样副本的状况。  

 

2) 可用性（Availability） ：(       全部在分布式系统活跃的节点都可以处理操做且能响应查询。)  

    可用性很简单，顾名思义，就是指在客户端想要访问数据的时候，能够获得响应。可是注意，系统可用（Available）并不表明存储系统全部节点提供的数据是一致的。这种状况，咱们仍然说系统是可用的。每每咱们会对不一样的应用设定一个最长响应时间，超过这个响应时间的服务咱们仍然称之为不可用的。   

 

3) 分区容忍性（Partition Tolerance） ：(       分区容错性: 在两个复制系统之间，若是发生了计划以外的网络链接问题，对于这种状况，有一套容错性设计来保证。)  

    若是你的存储系统只运行在一个节点上，要么系统整个崩溃，要么所有运行良好。一旦针对同一服务的存储系统分布到了多个节点后，整个存储系统就存在分区的可能性。好比，两个存储节点之间联通的网络断开（不管长时间或者短暂的），就造成了分区。通常来说，为了提升服务质量，同一份数据放置在不一样城市很是正常的。所以节点之间造成分区也很正常。  

    Gilbert 和Lynch将分区容忍性定义以下：除所有网络节点所有故障之外，全部子节点集合的故障都不容许致使整个系统不正确响应。即便部分的组件不可用，施加的操做也能够完成。  

     一个数据存储系统不可能同时知足上述三个特性，只能同时知足其两个特性，也就是： CA,CP,AP。能够这么说，当前全部的数据存储解决方案，均可以归类的上述三种类型。  

     CA  知足数据的一致性和高可用性，但没有可扩展性，如传统的关系型数据，基本上知足是这个解决方案，如ORACLE , MYSQL 的单节点，知足数据的一致性和高可用性。  

     CP  知足数据的一致性和分区性，如Oracle RAC ，Sybase 集群。虽然Oracle RAC具有一点的扩展性，但当节点达到必定数目时，性能（也便可用性）就会降低很快，而且节点之间的网络开销还在，须要实时同步各节点之间的数据。  

     AP 在性能和可扩展性方面表现不错，但在数据一致性方面会用牺牲，各节点的之间数据同步没有哪么快，但能保存数据的最终一致性。当前热炒的NOSQL大多类是典型的AP类型数据库。  

综合上述，架构师不要企图设计一套同是知足CAP三方面的数据库。只能在根据业务场景，对数据存储要求有所折衷。  

3.BASE  

    接受最终一致性的理论支撑是BASE模型，BASE全称是BasicallyAvailable（基本可用）, Soft-state（软状态/柔性事务）, Eventually Consistent（最终一致性）。BASE模型在理论逻辑上是相反于ACID（原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability）模型的概念，它牺牲高一致性，得到可用性和分区容忍性。  

    最终一致性：  

        最终一致性是指：通过一段时间之后，更新的数据会到达系统中的全部相关节点。这段时间就被称之为最终一致性的时间窗口  

CAP和ACID一致性区别  

    ACID一致性是有关数据库规则，若是数据表结构定义一个字段值是惟一的，那么一致性系统将解决全部操做中致使这个字段值非惟一性的状况，若是带有一个外键的一行记录被删除，那么其外键相关记录也应该被删除，这就是ACID一致性意思。  

    CAP理论的一致性是保证一样一个数据在全部不一样服务器上的拷贝都是相同的，这是一种逻辑保证，而不是物理，由于光速限制，在不一样服务器上这种复制是须要时间的，集群经过阻止客户端查看不一样节点上还未同步的数据维持逻辑视图。  

     CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。所以在进行分布式架构设计时，必须作出取舍。而对于分布式数 据系统，分区容忍性是基本要求 ，不然就失去了价值。所以设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应 用，其实并不须要强一致性，所以牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。(通常状况下CAP理论认为你不能拥有上述三种中两种，这是一个实践总结：当有网络分区状况下，也就是分布式系统中，你不能又要有完美一致性和100%的可用性，只能这二者选择一个。在单机系统中，你则须要在一致性和延迟性latency之间权衡)  

     固然，牺牲一致性，并非彻底无论数据的一致性，不然数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是再也不要求关系型数 据库中的强一致性，而是只要系统能达到最终一致性便可，考虑到客户体验，这个最终一致的时间窗口，要尽量的对用户透明，也就是须要保障“用户感知到的一致性”。一般是经过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则 取决于数据复制到一致状态的时间。  

 

最终一致性(eventually consistent)  

     对于一致性，能够分为从客户端和服务端两个不一样的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则 是更新如何复制分布到整个系统，以保证数据最终一致。一致性是由于有并发读写才有的问题，所以在理解一致性的问题时，必定要注意结合考虑并发读写的场景。

     从客户端角度，多进程并发访问时，更新过的数据在不一样进程如何获取的不一样策略，决定了不一样的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性 。若是能容忍后续的部分或者所有访问不到，则是弱一致性 。 若是通过一段时间后要求能访问到更新后的数据，则是最终一致性。  

    最终一致性根据更新数据后各进程访问到数据的时间和方式的不一样，又能够区分为：  

• 因果一致性 。若是进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入 将保证取代前一次写入。与进程A无因果关系的进程C的访问遵照通常的最终一致性规则。
• “读己之所写（read-your-writes）”一致性 。当进程A本身更新一个数据项以后，它老是访问到 更新过的值，毫不会看到旧值。这是因果一致性模型的一个特例。
• 会话（Session）一致性 。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要 会话还存在，系统就保证“读己之所写”一致性。若是因为某些失败情形令会话终止，就要创建新的会话，并且系统的保证不会延续到新的会话。
• 单调（Monotonic）读一致性 。若是进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那 个值以前的值。
• 单调写一致性 。系统保证来自同一个进程的写操做顺序执行。要是系统不能保证这种程度的一致性，就很是难以编程 了。

    上述最终一致性的不一样方式能够进行组合，例如单调读一致性和读己之所写一致性就能够组合实现。而且从实践的角度来看，这二者的组合，读取本身更新的数据，和一旦读取到最新的版本不会再读取旧版本，对于此架构上的程序开发来讲，会少不少额外的烦恼。  

     从服务端角度，如何尽快将更新后的数据分布到整个系统，下降达到最终一致性的时间窗口，是提升系统的可用度和用户体验很是重要的方面。对于分布式数 据系统：

• N — 数据复制的份数
• W — 更新数据是须要保证写完成的节点数
• R — 读取数据的时候须要读取的节点数

    若是W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则无论读 的是主库仍是备库的数据，都是一致的。

若是W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则若是读的是备库，就可能没法读取主库 已经更新过的数据，因此是弱一致性。

对于分布式系统，为了保证高可用性，通常设置N>=3。不一样的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不一样的应用场景。  

• 若是N=W,R=1，任何一个写节点失效，都会致使写失败，所以可用性会下降，可是因为数据分布的N个节点是同步写入的，所以能够保证强一致性。
• 若是N=R,W=1，只须要一个节点写入成功便可，写性能和可用性都比较高。可是读取其余节点的进程可能不能获取更新后的数据，所以是弱一致性。这种状况 下，若是W<(N+1)/2，而且写入的节点不重叠的话，则会存在写冲突