分布式理论：CAP定理与BASE理论

全文：Java-微服务下的分布式事务介绍及其解决方案-目录导航

---

第四步：在解决方案之前先了解些分布式理论：分布式理论

分布式理论

1、CAP定理

分布式理论有很多，这里说一下分布式理论基础-CAP定理。了解了CAP理论有助于我们研究分布式事务的处理方案。

CAP定理是由加州大学伯克利Eric Brewer教授提出来的，在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性（Consistence） :所有节点访问同一份最新的数据副本，这里说的是强一致性
• 可用性（Availability）:每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
• 分区容错性（Partition tolerance） : 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

通过下图再来理解一下CAP理论：

• 一致性(Consistency)：服务A、B、C三个结点都存储了用户数据， 三个结点的数据需要保持同一时刻数据一致性。
• 可用性(Availability)：服务A、B、C三个结点，其中一个结点宕机不影响整个集群对外提供服务，如果只有服务A结点，当服务A宕机整个系统将无法提供服务，增加服务B、C是为了保证系统的可用性。
• 分区容忍性(Partition Tolerance)：分区容忍性就是允许系统通过网络协同工作，分区容忍性要解决由于网络分区导致数据的不完整及无法访问等问题。在存在网络分区的情况下，仍然可以接受请求（满足一致性和可用性)。（分布式系统不可避免的出现了多个系统通过网络协同工作的场景，结点之间难免会出现网络中断、网延延迟等现象，这种现象一旦出现就导致数据被分散在不同的结点上，这就是网络分区）

CAP仅适用于原子读写的NOSQL场景中，并不适合数据库系统。

1.1、分布式系统能否兼顾C、A、P？

在保证分区容忍性的前提下一致性和可用性无法兼顾，如果要提高系统的可用性就要增加多个结点，如果要保证数据的一致性就要实现每个结点的数据一致，结点越多可用性越好，但是数据一致性越差。所以，在进行分布式系统设计时，同时满足“一致性”、“可用性”和“分区容忍性”三者是几乎不可能的

1.2、CAP有哪些组合方式？

• CA：放弃分区容忍性，加强一致性和可用性，关系数据库按照CA进行设计。
• AP：放弃一致性，加强可用性和分区容忍性，追求最终一致性，很多NoSQL数据库按照AP进行设计。
  说明：这里放弃一致性是指放弃强一致性，强一致性就是写入成功立刻要查询出最新数据。追求最终一致性是指允许暂时的数据不一致，只要最终在用户接受的时间内数据 一致即可
• CP：放弃可用性，加强一致性和分区容忍性，一些强一致性要求的系统按CP进行设计，比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。（ 说明：由于网络问题的存在，CP系统可能会出现待等待超时，如果没有处理超时问题，则整个系统会出现阻塞）

总结： 在分布式系统设计中AP的应用较多，即保证分区容忍性和可用性，牺牲数据的强一致性（写操作后立刻读取到最新数据），保证数据最终一致性。比如：订单退款，今日退款成功，明日账户到账，只要在预定的用户可以接受的时间内退款事务走完即可。

1.3、注意：不是所谓的3选2（不要被网上大多数文章误导了）:

大部分人解释这一定律时，常常简单的表述为：“一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到”。实际上这是一个非常具有误导性质的说法，而且在CAP理论诞生12年之后，CAP之父也在2012年重写了之前的论文。

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能2选1。也就是说当网络分区之后P是前提，决定了P之后才有C和A的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。

目前对于多数大型互联网应用的场景：节点众多、部署分散。而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9( 9.99.%)， 并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择: 保证P和A，舍弃C强一致性，保证最终致性。

如果想深入学习一下CAP看一下这篇文章吧，《分布式系统之CAP理论》 ：分布式系统之CAP理论

1.4、怎么通俗给别人介绍CAP呢？

经过上面介绍，我们知道P是分布式系统的前提，所以我们需要从P说起。

首先说下分区容错性P，一个机房（有多台机器），我们可以称之为一个分区，分区内部通信正常，分区之间由于网络故障导致无法通信，那这样整体的数据一致性就无法保证。分区容错性也就是指：当分区之间由于网络故障而导致的数据之间的不一致，这就是一个错误，我们为了解决这个错误，就要思考如何保证这样情况下各分区间的数据一致性，此时有个最暴力的方案就是停止对外服务，我先把内部数据一致性弄好，再对外服务，但是这就是完全牺牲了可用性。所以现在就出现了C与A之间的博弈，就是当数据不一致时，怎么既有可用性，也有数据一致性。（这一点可以参考kafka 的ISR机制，它的机制可以动态的调整数据一致性与可用性。）

2、BASE理论

BASE理论由eBay架构师Dan Pritchett提出，在2008年上被分表为论文，并且eBay给出了他们在实践中总结的基于BASE理论的一套新的分布式事务解决方案。

BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，它大大降低了我们对系统的要求。

2.1、BASE理论的核心思想

即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

针对数据库领域，BASE思想的主要实现是对业务数据进行拆分，让不同的数据分布在不同的机器上，以提升系统的可用性，当前主要有以下两种做法：

• 按功能划分数据库
• 分片（如开源的Mycat、Amoeba等）。

由于拆分后会涉及分布式事务问题，所以eBay在该BASE论文中提到了如何用最终一致性的思路来实现高性能的分布式事务。

2.2、BASE理论三要素

1. 基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。

比如：

• 响应时间上的损失:正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
• 系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

2. 软状态

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

3. 最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。