CAP和BASE理论

CAP和BASE理论

对于本地事务处理或者是集中式的事务处理系统，很显然咱们能够采用已经被实践证实很成熟的ACID模型来保证数据的严格一致性。而随着分布式事务的出现，传统的单机事务模型已经没法胜任。尤为是对于一个高访问量、高并发的互联网分布式系统来讲，若是咱们指望实现一套严格知足ACID特性的分布式事务，极可能出现的状况就是在系统的可用性和严格一致性之间出现冲突——由于当咱们要求分布式系统具备严格一致性时，极可能就须要牺牲掉系统的可用性。但毋庸置疑的一点是，可用性又是一个全部消费者不容许咱们讨价还价的系统属性，好比说像淘宝网这样的在线购物网站，就要求它可以7?24小时不间断地对外提供服务，而对于一致性，则更加是全部消费者对于一个软件系统的刚需。所以，在可用性和一致性之间永远没法存在一个一箭双鵰的方案，因而如何构建一个兼顾可用性和一致性的分布式系统成为了无数工程师探讨的难题，出现了诸如CAP和BASE这样的分布式系统经典理论。

 

CAP定理

2000年7月，来自加州大学伯克利分校的Eric Brewer教授注 在ACM PODC（Principles of Distributed Computing）会议上，首次提出了著名的CAP猜测。2年后，来自麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证实了Brewer教授CAP猜测的可行性注 ，今后，CAP理论正式在学术上成为了分布式计算领域的公认定理，并深深地影响了分布式计算的发展。

CAP理论告诉咱们，一个分布式系统不可能同时知足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时知足其中的两项。

 

• 一致性(Consistency)

A read is guaranteed to return the most recent write for a given client.（对某个指定的客户端来讲，读操做保证可以返回最新的写操做结果）

在分布式环境中，一致性是指数据在多个副本之间是否可以保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操做后，应该保证系统的数据仍然处于一致的状态。

对于一个将数据副本分布在不一样分布式节点上的系统来讲，若是对第一个节点的数据进行了更新操做而且更新成功后，却没有使得第二个节点上的数据获得相应的更新，因而在对第二个节点的数据进行读取操做时，获取的依然是老数据（或称为脏数据），这就是典型的分布式数据不一致状况。在分布式系统中，若是可以作到针对一个数据项的更新操做执行成功后，全部的用户均可以读取到其最新的值，那么这样的系统就被认为具备强一致性（或严格的一致性）。

• 可用性(Availability)

A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).（对某个指定的客户端来讲，读操做保证可以返回最新的写操做结果）

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每个操做请求老是可以在有限的时间内返回结果。这里咱们重点看下“有限的时间内”和“返回结果”。

“有限的时间内”是指，对于用户的一个操做请求，系统必须可以在指定的时间（即响应时间）内返回对应的处理结果，若是超过了这个时间范围，那么系统就被认为是不可用的。另外，“有限的时间内”是一个在系统设计之初就设定好的系统运行指标，一般不一样的系统之间会有很大的不一样。好比说，对于一个在线搜索引擎来讲，一般在0.5秒内须要给出用户搜索关键词对应的检索结果。以Google为例，搜索“分布式”这一关键词，Google可以在0.3秒左右的时间，返回大约上千万条检索结果。而对于一个面向HIVE的海量数据查询平台来讲，正常的一次数据检索时间可能在20秒到30秒之间，而若是是一个时间跨度较大的数据内容查询，“有限的时间”有时候甚至会长达几分钟。

从上面的例子中，咱们能够看出，用户对于一个系统的请求响应时间的指望值不尽相同。可是，不管系统之间的差别有多大，惟一相同的一点就是对于用户请求，系统必须存在一个合理的响应时间，不然用户便会对系统感到失望。

“返回结果”是可用性的另外一个很是重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果一般可以明确地反映出对请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。

让咱们再来看看上面提到的在线搜索引擎的例子，若是用户输入指定的搜索关键词后，返回的结果是一个系统错误，一般相似于“OutOfMemoryError”或“System Has Crashed”等提示语，那么咱们认为此时系统是不可用的。

• 分区容忍性(Partition Tolerance)

The system will continue to function when network partitions occur.（当出现网络分区后，系统可以继续“履行职责”）

分区容错性约束了一个分布式系统须要具备以下特性：分布式系统在遇到任何网络分区故障的时候，仍然须要可以保证对外提供知足一致性和可用性的服务，除非是整个网络环境都发生了故障。

网络分区是指在分布式系统中，不一样的节点分布在不一样的子网络（机房或异地网络等）中，因为一些特殊的缘由致使这些子网络之间出现网络不连通的情况，但各个子网络的内部网络是正常的，从而致使整个系统的网络环境被切分红了若干个孤立的区域。须要注意的是，组成一个分布式系统的每一个节点的加入与退出均可以看做是一个特殊的网络分区。

 

以上就是对CAP定理中一致性、可用性和分区容错性的讲解，一般使用图1-2所示的示意图来表示CAP定理。

既然在上文中咱们提到，一个分布式系统没法同时知足上述三个需求，而只能知足其中的两项，所以在进行对CAP定理的应用时，咱们就须要抛弃其中的一项，表1-2所示是抛弃CAP定理中任意一项特性的场景说明。

 

表1-2．CAP定理应用

	说明
放弃P	若是但愿可以避免系统出现分区容错性问题，一种较为简单的作法是将全部的数据（或者仅仅是那些与事务相关的数据）都放在一个分布式节点上。这样的作法虽然没法100%地保证系统不会出错，但至少不会碰到因为网络分区带来的负面影响。但同时须要注意的是，放弃P的同时也就意味着放弃了系统的可扩展性。
放弃A	相对于放弃“分区容错性”来讲，放弃可用性则正好相反，其作法是一旦系统遇到网络分区或其余故障时，那么受到影响的服务须要等待必定的时间，所以在等待期间系统没法对外提供正常的服务，即不可用。
放弃C	这里所说的放弃一致性，并非彻底不须要数据一致性，若是真是这样的话，那么系统的数据都是没有意义的，整个系统也是没有价值的。 事实上，放弃一致性指的是放弃数据的强一致性，而保留数据的最终一致性。这样的系统没法保证数据保持实时的一致性，可是可以承诺的是，数据最终会达到一个一致的状态。这就引入了一个时间窗口的概念，具体多久可以达到数据一致取决于系统的设计，主要包括数据副本在不一样节点之间的复制时间长短。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

从CAP定理中咱们能够看出，一个分布式系统不可能同时知足一致性、可用性和分区容错性这三个需求。另外一方面，须要明确的一点是，对于一个分布式系统而言，分区容错性能够说是一个最基本的要求。为何这样说，其实很简单，由于既然是一个分布式系统，那么分布式系统中的组件必然须要被部署到不一样的节点，不然也就无所谓分布式系统了，所以必然出现子网络。而对于分布式系统而言，网络问题又是一个一定会出现的异常状况，所以分区容错性也就成为了一个分布式系统必然须要面对和解决的问题。所以系统架构设计师每每须要把精力花在如何根据业务特色在C（一致性）和A（可用性）之间寻求平衡。

 

BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，是由来自eBay的架构师Dan Pritchett在其文章BASE: An Acid Alternative注 中第一次明确提出的。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，其核心思想是即便没法作到强一致性(Strong consistency)，但每一个应用均可以根据自身的业务特色，采用适当的方式来使系统达到最终一致性(Eventual consistency)。接下来咱们着重对BASE中的三要素进行详细讲解。

 

BASE理论是基于CAP定理逐步演化而来的，其核心思想是即便没法作到强一致性（Strong consistency），但每一个应用均可以根据自身的业务特色，采用适当的方式来使系统达到最终一致性（Eventual consistency）

 

• Basically Available（基本可用）

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

响应时间上的损失：正常状况下，一个在线搜索引擎须要在0.5秒以内返回给用户相应的查询结果，但因为出现故障（好比系统部分机房发生断电或断网故障），查询结果的响应时间增长到了1～2秒。

功能上的损失：正常状况下，在一个电子商务网站上进行购物，消费者几乎可以顺利地完成每一笔订单，可是在一些节日大促购物高峰的时候，因为消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

 

• Soft state（软状态）

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

分布式存储中通常一份数据多个副本，容许不一样节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

 

• Eventually consistent（最终一致性）

最终一致性强调的是系统中全部的数据副本，在通过一段时间的同步后，最终可以达到一个一致的状态。所以，最终一致性的本质是须要系统保证最终数据可以达到一致，而不须要实时保证系统数据的强一致性。

亚马逊首席技术官Werner Vogels在于2008年发表的一篇经典文章Eventually Consistent-Revisited中，对最终一致性进行了很是详细的介绍。他认为最终一致性是一种特殊的弱一致性：系统可以保证在没有其余新的更新操做的状况下，数据最终必定可以达到一致的状态，所以全部客户端对系统的数据访问都可以获取到最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟、系统负载和数据复制方案设计等因素。

 

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

• 因果一致性（Causal consistency）

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

• 读己之所写（Read your writes）

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

• 会话一致性（Session consistency）

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

• 单调读一致性（Monotonic read consistency）

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

• 单调写一致性（Monotonic write consistency）

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

 

在实际系统实践中，能够将其中的若干个变种互相结合起来，以构建一个具备最终一致性特性的分布式系统。事实上，最终一致性并非只有那些大型分布式系统才涉及的特性，许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中，大多都会采用同步和异步方式来实现主备数据复制技术。在同步方式中，数据的复制过程一般是更新事务的一部分，所以在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新每每会存在延时，这取决于事务日志在主备数据库之间传输的时间长短，若是传输时间过长或者甚至在日志传输过程当中出现异常致使没法及时将事务应用到备库上，那么很显然，从备库中读取的数据将是旧的，所以就出现了数据不一致的状况。固然，不管是采用屡次重试仍是人为数据订正，关系型数据库仍是可以保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。

 

总结 

BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性是相反的，它彻底不一样于ACID的强一致性模型，而是提出经过牺牲强一致性来得到可用性，并容许数据在一段时间内是不一致的，但最终达到一致状态。

但同时，在实际的分布式场景中，不一样业务单元和组件对数据一致性的要求是不一样的，所以在具体的分布式系统架构设计过程当中，ACID特性与BASE理论每每又会结合在一块儿使用。