Cap定理和Base理论

Cap 原则

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

分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了以下概括：

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

一致性与可用性的抉择编辑

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而因为当前的网络硬件确定会出现延迟丢包等问题，因此分区容忍性使咱们必需要实现的。因此咱们只能在一致性和可用性之间进行权衡，没有NOSQL系统能同时保证这三点。对于web2.0网站来讲，关系数据库的不少主要特性却每每无用武之地。

1.数据库事务一致性需求

不少web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求不高，容许实现最终一致。（什么场景？？？）

2.数据库的写实时性和读实时性需求

对关系数据库来讲，插入一条数据以后马上查询，是确定能够读出来这条数据的，可是对于不少web应用来讲，并不要求这么高的实时性。好比说：发送一条消息后，过几秒乃至十几秒以后，个人订阅者才看到这条动态是彻底能够接受的。

3.对复杂的SQL查询，特别是多表关联查询的需求

　　任何大数据量的web系统，都很是忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种状况的产生。每每更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

Base理论

BASE是 Basically Available（基本可用），Soft state （软状态）和Eventually Consistency（最终一致）三个词语的简写。Base是对CAP中一致性和可用性权衡的结果，其来源与对大规模互联网系统分布式时间的结论，是基于CAP定理逐步演化而来的，其核心思想是即便没法作到强一致性（Strong Consistency），但每一个应用均可以根据自身的业务特色，采用是低昂的方式来使系统达到最终一致性（Eventual consistency）。

基本可用（Basically Available）

基本可用是指分布式系统在出现不可预知故障的时候，容许损失部分可用性--但注意，这毫不等价与系统不可用，如下两个就是"基本可用"的典型例子。

1. 响应时间上的损失：正常状况下，一个在线搜索引擎须要0.5秒内返回给用户响应的查询结果，但因为出现异常（好比系统部分机房发生断电或断网故障），查询结果的响应时间增长的了 1~2秒。
2. 功能上的损失：正常状况下，在一个电子商务网站上进行购物，消费者几乎可以顺利地完成每一笔订单，可是在一些节日大促购物高峰的时候，因为消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

软状态（Soft state）

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

最终一致性

最终一致性强调的是系统中全部的数据副本，在通过一段时间的同步后，最终可以达到一个一致的状态。所以，最终一致性的本质是须要系统保证最终数据可以达到一致，而不须要实时保证系统数据的强一致性 在实际工程实践中，最终一致性存在如下五类主要变种。

因果一致性：

因果一致性是指，若是进程A在更新完某个数据项后通知了进程B，那么进程B以后对该数据项的访问都应该可以获取到进程A更新后的最新值，而且若是进程B要对该数据项进行更新操做的话，务必基于进程A更新后的最新值，即不能发生丢失更新状况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。

读己之所写：

读己之所写是指，进程A更新一个数据项以后，它本身老是可以访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者而言，其读取到的数据必定不会比本身上次写入的值旧。所以，读己之所写也能够看做是一种特殊的因果一致性。

会话一致性：

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

单调读一致性：

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

单调写一致性：

单调写一致性是指，一个系统须要可以保证来自同一个进程的写操做被顺序地执行。

总的来讲，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性使相反的，它彻底不一样于ACID的强一致性模型，而是提出经过牺牲强一致性来得到可用性，并容许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不一样业务单元和组件对数据一致性的要求是不一样的，所以在具体的分布式系统架构设计过程当中，ACID特性与BASE理论每每又会结合在一块儿使用。

为何会是这样

咱们来看一个简单的问题, 一个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，只能查看信息不能更新信息有时候从产品层面还不如直接拒绝服务）

分布式系统的典型应用

分布式系统是一个很是普遍的概念，它最终要落实到解决实际问题上，不一样的问题有不一样的方法和架构。全部的开源软件都是以某个应用场景出现，而纯粹以“分布式”概念进行划分的比较少见。 但若是以算法划分，到能分出几类：

1.以Leader选举为主的一类算法，好比paxos、viewstamp，就是如今zookeeper、Chuby等工具的主体

2.以分布式事务为主的一类主要是二段提交，这些分布式数据库管理器及数据库都支持

3.以若一致性为主的，主要表明是Cassandra的W、R、N可调节的一致性

4.以租赁机制为主的，主要是一些分布式锁的概念，目前尚未看到纯粹“分布式”锁的实现

5.以失败探测为主的，主要是Gossip和phi失败探测算法，固然也包括简单的心跳

6.以弱一致性、因果一致性、顺序一致性为主的，开源尚很少，但大都应用在Linkedin、Twitter、Facebook等公司内部

7固然以异步解耦为主的，还有各种Queue

5、ACID和BASE的区别与联系

ACID是传统数据库经常使用的设计理念，追求强一致性模型。BASE支持的是大型分布式系统，提出经过牺牲强一致性得到高可用性。

ACID和BASE表明了两种截然相反的设计哲学，在分布式系统设计的场景中，系统组件对一致性要求是不一样的，所以ACID和BASE又会结合使用。