从分布式一致性谈到CAP理论、BASE理论

问题的提出

在计算机科学领域，分布式一致性是一个至关重要且被普遍探索与论证问题，首先来看三种业务场景。

一、火车站售票

假如说咱们的终端用户是一位常常坐火车的旅行家，一般他是去车站的售票处购买车票，而后拿着车票去检票口，再坐上火车，开始一段美好的旅行----一切彷佛都是那么和谐。想象一下，若是他选择的目的地是杭州，而某一趟开往杭州的火车只剩下最后一张车票，可能在同一时刻，不一样售票窗口的另外一位乘客也购买了同一张车票。假如说售票系统没有进行一致性的保障，两人都购票成功了。而在检票口检票的时候，其中一位乘客会被告知他的车票无效----固然，现代的中国铁路售票系统已经不多出现这样的问题了。但在这个例子中咱们能够看出，终端用户对于系统的需求很是简单：

"请售票给我，若是没有余票了，请在售票的时候就告诉我票是无效的"

这就对购票系统提出了严格的一致性要求----系统的数据（本例中指的就是那趟开往杭州的火车的余票数）不管在哪一个售票窗口，每时每刻都必须是准确无误的！

二、银行转帐

假如咱们的终端用户是一位刚毕业的大学生，一般在拿到第一个月工资的时候，都会选择向家里汇款。当他来到银行柜台，完成转帐操做后，银行的柜台服务员会友善地提醒他："您的转帐将在N个工做往后到帐！"。此时这名毕业生有必定的沮丧，会对那名柜台服务员叮嘱："好吧，多久不要紧，钱不要少就行了！"----这也成为了几乎全部用户对于现代银行系统最基本的需求

三、网上购物

假如说咱们的终端用户是一位网购达人，当他看见一件库存量为5的心仪商品，会迅速地确认购买，写下收货地址，而后下单----然而，在下单的那个瞬间，系统可能会告知该用户："库存量不足！"。此时绝大部分消费者都会抱怨本身动做太慢，使得心爱的商品被其余人抢走了。

但其实有过网购系统开发经验的工程师必定明白，在商品详情页上显示的那个库存量，一般不是该商品的真实库存量，只有在真正下单购买的时候，系统才会检查该商品的真实库存量。可是，谁在乎呢？

 

问题的解读

对于上面三个例子，相信你们必定看出来了，咱们的终端用户在使用不一样的计算机产品时对于数据一致性的需求是不同的：

一、有些系统，既要快速地响应用户，同时还要保证系统的数据对于任意客户端都是真实可靠的，就像火车站售票系统

二、有些系统，须要为用户保证绝对可靠的数据安全，虽然在数据一致性上存在延时，但最终务必保证严格的一致性，就像银行的转帐系统

三、有些系统，虽然向用户展现了一些能够说是"错误"的数据，可是在整个系统使用过程当中，必定会在某一个流程上对系统数据进行准确无误的检查，从而避免用户发生没必要要的损失，就像网购系统

 

分布一致性的提出

在分布式系统中要解决的一个重要问题就是数据的复制。在咱们的平常开发经验中，相信不少开发人员都遇到过这样的问题：假设客户端C1将系统中的一个值K由V1更新为V2，但客户端C2没法当即读取到K的最新值，须要在一段时间以后才能读取到。这很正常，由于数据库复制之间存在延时。

分布式系统对于数据的复制需求通常都来自于如下两个缘由：

一、为了增长系统的可用性，以防止单点故障引发的系统不可用

二、提升系统的总体性能，经过负载均衡技术，可以让分布在不一样地方的数据副本都可以为用户提供服务

数据复制在可用性和性能方面给分布式系统带来的巨大好处是不言而喻的，然而数据复制所带来的一致性挑战，也是每个系统研发人员不得不面对的。

所谓分布一致性问题，是指在分布式环境中引入数据复制机制以后，不一样数据节点之间可能出现的，并没有法依靠计算机应用程序自身解决的数据不一致的状况。简单讲，数据一致性就是指在对一个副本数据进行更新的时候，必须确保也可以更新其余的副本，不然不一样副本之间的数据将不一致。

那么如何解决这个问题？一种思路是"既然是因为延时动做引发的问题，那我能够将写入的动做阻塞，直到数据复制完成后，才完成写入动做"。没错，这彷佛能解决问题，并且有一些系统的架构也确实直接使用了这个思路。但这个思路在解决一致性问题的同时，又带来了新的问题：写入的性能。若是你的应用场景有很是多的写请求，那么使用这个思路以后，后续的写请求都将会阻塞在前一个请求的写操做上，致使系统总体性能急剧降低。

总得来讲，咱们没法找到一种可以知足分布式系统全部系统属性的分布式一致性解决方案。所以，如何既保证数据的一致性，同时又不影响系统运行的性能，是每个分布式系统都须要重点考虑和权衡的。因而，一致性级别由此诞生：

一、强一致性

这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来每每对系统的性能影响大

二、弱一致性

这种一致性级别约束了系统在写入成功后，不承诺当即能够读到写入的值，也不久承诺多久以后数据可以达到一致，但会尽量地保证到某个时间级别（好比秒级别）后，数据可以达到一致状态

三、最终一致性

最终一致性是弱一致性的一个特例，系统会保证在必定时间内，可以达到一个数据一致的状态。这里之因此将最终一致性单独提出来，是由于它是弱一致性中很是推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型

 

分布式环境的各类问题

分布式系统体系结构从其出现之初就伴随着诸多的难题和挑战：

一、通讯异常

从集中式向分布式演变的过程当中，必然引入网络因素，因为网络自己的不可靠性，所以也引入了额外的问题。分布式系统须要在各个节点之间进行网络通讯，所以每次网络通讯都会伴随着网络不可用的风险，网络光纤、路由器或是DNS等硬件设备或是系统不可用都会致使最终分布式系统没法顺利完成一次网络通讯。另外，即便分布式系统各个节点之间的网络通讯可以正常进行，其延时也会大于单机操做。一般咱们认为现代计算机体系结构中，单机内存访问的延时在纳秒数量级（一般是10ns），而正常的一次网络通讯的延迟在0.1~1ms左右（至关于内存访问延时的105倍），如此巨大的延时差异，也会影响到消息的收发过程，所以消息丢失和消息延迟变得很是广泛

二、网络分区

当网络因为发生异常状况，致使分布式系统中部分节点之间的网络延时不断增大，最终致使组成分布式系统的全部节点中，只有部分节点之间可以正常通讯，而另外一些节点则不能----咱们将这个现象称为网络分区。当网络分区出现时，分布式系统会出现局部小集群，在极端状况下，这些局部小集群会独立完成本来须要整个分布式系统才能完成的功能，包括对数据的事物处理，这就对分布式一致性提出了很是大的挑战

三、三态

上面两点，咱们已经了解到在分布式环境下，网络可能会出现各式各样的问题，所以分布式系统的每一次请求与响应，存在特有的三态概念，即成功、失败、超时。在传统的单机系统中，应用程序在调用一个函数以后，可以获得一个很是明确的响应：成功或失败。而在分布式系统中，因为网络是不可靠的，虽然在绝大部分状况下，网络通讯也可以接受到成功或失败的响应，当时当网络出现异常的状况下，就可能会出现超时现象，一般有如下两种状况：

（1）因为网络缘由，该请求并无被成功地发送到接收方，而是在发送过程当中就发生了消息丢失现象

（2）该请求成功地被接收方接收后，进行了处理，可是在将响应反馈给发送方的过程当中，发生了消息丢失现象

当出现这样的超时现象时，网络通讯的发起方是没法肯定当前请求是否被成功处理的

四、节点故障

节点故障则是分布式环境下另外一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象，一般根据经验来讲，每一个节点都有可能出现故障，而且天天都在发生

 

分布式事物

随着分布式计算的发展，事物在分布式计算领域也获得了普遍的应用。在单机数据库中，咱们很容易可以实现一套知足ACID特性的事物处理系统，但在分布式数据库中，数据分散在各台不一样的机器上，如何对这些数据进行分布式的事物处理具备很是大的挑战。

分布式事物是指事物的参与者、支持事物的服务器、资源服务器以及事物管理器分别位于分布式系统的不一样节点上，一般一个分布式事物中会涉及对多个数据源或业务系统的操做。

能够设想一个最典型的分布式事物场景：一个跨银行的转帐操做涉及调用两个异地的银行服务，其中一个是本地银行提供的取款服务，另外一个则是目标银行提供的存款服务，这两个服务自己是无状态而且相互独立的，共同构成了一个完整的分布式事物。若是从本地银行取款成功，可是由于某种缘由存款服务失败了，那么就必须回滚到取款以前的状态，不然用户可能会发现本身的钱不知去向了。

从这个例子能够看到，一个分布式事务能够看作是多个分布式的操做序列组成的，例如上面例子的取款服务和存款服务，一般能够把这一系列分布式的操做序列称为子事物。所以，分布式事务也能够被定义为一种嵌套型的事物，同时也就具备了ACID事物特性。但因为在分布式事务中，各个子事物的执行是分布式的，所以要实现一种可以保证ACID特性的分布式事物处理系统就显得格外复杂。

 

CAP理论

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

一、一致性

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

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

二、可用性

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

"有限时间内"是指，对于用户的一个操做请求，系统必须可以在指定的时间内返回对应的处理结果，若是超过了这个时间范围，那么系统就被认为是不可用的。另外，"有限的时间内"是指系统设计之初就设计好的运行指标，一般不一样系统之间有很大的不一样，不管如何，对于用户请求，系统必须存在一个合理的响应时间，不然用户便会对系统感到失望。

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

三、分区容错性

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

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

既然一个分布式系统没法同时知足一致性、可用性、分区容错性三个特色，因此咱们就须要抛弃同样：

用一张表格说明一下：

选    择	说    明
CA	放弃分区容错性，增强一致性和可用性，其实就是传统的单机数据库的选择
AP	放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是不少分布式系统设计时的选择，例如不少NoSQL系统就是如此
CP	放弃可用性，追求一致性和分区容错性，基本不会选择，网络问题会直接让整个系统不可用

须要明确的一点是，对于一个分布式系统而言，分区容错性是一个最基本的要求。由于既然是一个分布式系统，那么分布式系统中的组件必然须要被部署到不一样的节点，不然也就无所谓分布式系统了，所以必然出现子网络。而对于分布式系统而言，网络问题又是一个一定会出现的异常状况，所以分区容错性也就成为了一个分布式系统必然须要面对和解决的问题。所以系统架构师每每须要把精力花在如何根据业务特色在C（一致性）和A（可用性）之间寻求平衡。

 

BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即便没法作到强一致性，但每一个应用均可以根据自身业务特色，采用适当的方式来使系统达到最终一致性。接下来看一下BASE中的三要素：

一、基本可用

基本可用是指分布式系统在出现不可预知故障的时候，容许损失部分可用性----注意，这毫不等价于系统不可用。好比：

（1）响应时间上的损失。正常状况下，一个在线搜索引擎须要在0.5秒以内返回给用户相应的查询结果，但因为出现故障，查询结果的响应时间增长了1~2秒

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

二、软状态

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

三、最终一致性

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

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