分布式系列文章——从ACID到CAP/BASE

事务

事务的定义：

事务（Transaction）是由一系列对系统中数据进行访问与更新的操做所组成的一个程序执行逻辑单元（Unit），狭义上的事务特指数据库事务。

事务的做用：

• 当多个应用程序并发访问数据库时，事务能够在这些应用程序之间提供一个隔离方法，以防止彼此的操做相互干扰。

• 事务为数据库操做序列提供了一个从失败中恢复到正常状态的方法，同时提供了数据库即便在异常状态下仍能保持数据一致性的方法。

事务具备四个特性，分别是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）,简称为事务的ACID特性。

ACID

原子性

事务的原子性是指事务必须是一个原子的操做序列单元。事务中包含的各项操做在一次执行过程当中，要么所有执行，要么所有不执行。

任何一项操做失败都将致使整个事务失败，同时其余已经被执行的操做都将被撤销并回滚。只有全部的操做所有成功，整个事务才算是成功完成。

一致性

事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行先后，数据库都必须处于一致性状态。换句话说，事务的执行结果必须是使数据库从一个一致性状态转变到另外一个一致性状态。

举个例子

银行的转帐操做就是一个事务。假设A和B原来帐户都有100元。此时A转帐给B50元，转帐结束后，应该是A帐户减去50元变成50元，B帐户增长50元变成150元。A、B的帐户总和仍是200元。转帐先后，数据库就是从一个一致性状态（A100元，B100元，A、B共200元）转变到另外一个一致性状态（A50元，B150元，A、B共200元）。假设转帐结束后只扣了A帐户，没有增长B帐户，这时数据库就处于不一致的状态。

隔离性

事务的隔离性是指在并发环境中，并发的事务是相互隔离的，事务之间互不干扰。

在标准的SQL规范中，定义的4个事务隔离级别，不一样隔离级别对事务的处理不一样。4个隔离级别分别是：未受权读取、受权读取、可重复读取和串行化。

下表展现了不一样隔离级别下事务访问数据的差别

隔离级别	脏读	可重复读	幻读
未受权读取	存在	不能够	存在
受权读取	不存在	不能够	存在
可重复读取	不存在	能够	存在
串行化	不存在	能够	不存在

以上4个级别的隔离性依次加强，分别解决不一样的问题。事务隔离级别越高，就越能保证数据的完整性和一致性，但同时对并发性能的影响也越大。

一般，对于绝大多数的应用来讲，能够优先考虑将数据库系统的隔离级别设置为受权读取，这可以在避免脏读的同时保证较好的并发性能。尽管这种事务隔离级别会致使不可重复读、幻读和第二类丢失更新等并发问题，但较为科学的作法是在可能出现这类问题的个别场合中，由应用程序主动采用悲观锁或乐观锁来进行事务控制。

持久性

事务的持久性又称为永久性，是指一个事务一旦提交，对数据库中对应数据的状态变动就应该是永久性的。即便发生系统崩溃或机器宕机等故障，只要数据库可以从新启动，那么必定可以将其恢复到事务成功结束时的状态。

分布式事务

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

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

举个例子来讲明分布式事务。一个最典型的分布式事务场景是跨行的转帐操做。该操做涉及调用两个异地的银行服务。其中一个是本地银行提供的取款服务，另外一个是目标银行提供的存款服务，这两个服务自己是无状态且相互独立的，共同构成了一个完整的分布式事务。取款和存款两个步骤要么都执行，要么都不执行。不然，若是从本地银行取款成功，可是由于某种缘由存款服务失败了，那么必须回滚到取款以前的状态，不然就会致使数据不一致。

从上面的例子能够看出，一个分布式事务能够看做是由多个分布式操做序列组成的，例如上面例子中的取款服务和存款服务，一般能够把这一系列分布式的操做序列称为子事务。因为分布式事务中，各个子事务的执行是分布式的，所以要实现一种可以保证ACID特性的分布式事务处理系统就显得格外复杂。

CAP定理

CAP定理：

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

一致性

在分布式环境中，一致性是指数据在多个副本之间是否可以保持一致的特性（这点跟ACID中的一致性含义不一样）。

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

可用性

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每个操做请求老是可以在有限的时间内返回结果，若是超过了这个时间范围，那么系统就被认为是不可用的。

『有限的时间内』是一个在系统设计之初就设定好的运行指标，不一样的系统会有很大的差异。好比对于一个在线搜索引擎来讲，一般在0.5秒内须要给出用户搜索关键词对应的检索结果。而对应Hive来讲，一次正常的查询时间可能在20秒到30秒之间。

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

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

分区容错性

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

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

以上就是对CAP定理中一致性、可用性和分区容错性的讲解。

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

CAP	说明
放弃P	若是但愿可以避免系统出现分区容错性问题，一种较为简单的作法是将全部的数据（或者仅仅是哪些与事务相关的数据）都放在一个分布式节点上。这样作虽然没法100%保证系统不会出错，但至少不会碰到因为网络分区带来的负面影响。但同时须要注意的是，放弃P的同时也就意味着放弃了系统的可扩展性
放弃A	一旦系统遇到网络分区或其余故障或为了保证一致性时，放弃可用性，那么受到影响的服务须要等待必定的时间，所以在等待期间系统没法对外提供正常的服务，即不可用
放弃C	这里所说的放弃一致性，实际上指的是放弃数据的强一致性，而保留数据的最终一致性。这样的系统没法保证数据保持实时的一致性，可是可以承诺的是，数据最终会达到一个一致的状态。

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

BASE理论

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

基本可用

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

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

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

软状态

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

最终一致性

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

最终一致性是一种特殊的弱一致性：系统可以保证在没有其余新的更新操做的状况下，数据最终必定可以达到一致的状态，所以全部客户端对系统的数据访问都可以获取到最新的值。同时，在没有发生故障的前提下，数据到达一致状态的时间延迟，取决于网络延迟、系统负载和数据复制方案设计等因素。

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

• 因果一致性(Causal consistency)
• 读己之所写(Read your writes)
• 会话一致性(Session consistency)
• 单调读一致性(Monotonic read consistency)
• 单调写一致性(Monotonic write consistency)

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

参考资料

• 《从Paxos到ZooKeeper——分布式一致性原理与实践》

欢迎关注公众号: FullStackPlan 获取更多干货哦~