分布式原理 - 一致性原理出发谈CAP、BASE

目录

1、概念：分布式一致性

1、1 场景理解

1、2 事件的四个特性：ACID

2、一致性的级别

3、CAP理论

4、BASE理论

---

 

学习分布式原理笔记，争取深入浅出。整理思路过程为，提出概念---场景理解---实际运用---总结。

---

1、概念：分布式一致性

• 变量说法：分布式系统通常由异步网络连接的多个节点构成，每个节点有独立的计算和存储，节点之间通过网络通信进行协作。分布式一致性指多个节点对某一变量的取值达成一致，一旦达成一致，则变量的本次取值即被确定。
• 数据（可能有数据副本）说法：在分布式存储系统中，通常以多副本冗余的方式实现数据的可靠存储。数据内容一致：同一份数据的多个副本必须保证一致，而数据的多个副本又存储在不同的节点中，这里的分布式一致性问题就是存储在不同节点中的数据副本（或称为变量）的取值必须一致；取值序列一致（操作序列一致）：不仅如此，因为变量是可变的，变量会有多次取值，变量的多次取值构成一个序列，分布式一致性还要求多个节点对该变量的取值序列必须一致。

在大量客户端并发请求读/写的情况下，维护数据多副本的一致性无疑非常重要，且富有挑战。一致性的三个主要元素是时间、事件、顺序，一致性所讨论的就是在这三个元素下，对分布式数据保持一致性的问题。下面将通过实际场景进行理解。

---

1、1 场景理解

如下图所示，分布式终端向客户提供服务（或者客户本身就是分布式终端，比如购物场景）。在服务过程的时间线上，每个时间点可能对应不同的事件，这些事件大多是对分布式系统中储存的数据进行一系列操作（常见的增删改查），而且这些事件是具有一定的顺序的。

系统需要保证的一致性就是指，在按照事件顺序每次执行完一次事件之后的时间点上，各个分布式终端能够获取的最新数据是按照事件逻辑及时更新了的数据。

具体场景理解可以参考抢购火车票、抢购商品等场景。

终端用户在使用不同的计算机产品时对于数据一致性的需求是不一样的：

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

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

3、绝对可靠（数据显示可能不及时，但是本质上保证数据的绝对可靠）：有些系统，虽然向用户展示了一些可以说是"错误"的数据，但是在整个系统使用过程中，一定会在某一个流程上对系统数据进行准确无误的检查，从而避免用户发生不必要的损失，就像网购系统

 

---

1、2 事件的四个特性：ACID

ACID是数据库（DBMS）事务正确执行所必须满足的四个特性的首字母缩写。

• Atomicity（原子性）：一个事务的所有操作，要么全部完成，要么全部不完成。所谓事务，是指由一系列数据操作所组成的完整逻辑过程。比如银行转账事务由两个操作组成：从源账户扣除金额，以及向目标账户增加金额。
• Consistency（一致性）：指事务开始之前和事务结束之后，数据的完整性约束没有被破坏。包含两层含义：

a)数据库机制层面，事务执行前后，数据能符合设置的约束，如唯一约束、外键约束；b)业务层面，由应用开发人员保证业务一致性。还是以银行转账为例，A、B两个账号，转账之前和之后，A、B两个账号余额总额必须一致。

• Isolation（隔离性）：数据库能够防止由于多个并发事务交叉执行而导致数据的不一致。（如上图的t1时刻）
• Durability（持久性）：指事务结束后，对数据的修改是永久的，不会回滚到之前的状态。

---

2、一致性的级别

前面讨论了一致性的概念，并且结合场景进行了理解。现在又来看一个概念，叫做分布式数据复制（概念）。

在我们的日常开发经验中，有这样的问题：假设客户端C1将系统中的一个值K由V1更新为V2，但客户端C2无法立即读取到K的最新值，需要在一段时间之后才能读取到。这很正常，因为数据库复制之间存在延时。

为什么需要分布式数据复制？

• 避免单点故障：传统的中心式系统的服务器可能存在单点故障，分布式系统就考虑在所有分布式节点上都保留一份系统的数据副本，这就是分布式数据复制；
• 高效提供服务：与此同时，可以通过负载均衡技术，能够让分布在不同地方的数据副本都能够为用户提供服务。

分布式数据复制带来的问题？

• 分布式数据一致性问题（就是前面讨论的一致性问题）：在分布式环境中引入数据复制机制之后，不同数据节点之间可能出现的，并无法依靠计算机应用程序自身解决的数据不一致的情况。简单讲，数据一致性就是指在对一个副本数据进行更新的时候，必须确保也能够更新其他的副本，否则不同副本之间的数据将不一致。

如何解决这个问题呢？

一种思路是"既然是由于延时动作引起的问题，那我可以将写入的动作阻塞，直到数据复制完成后，才完成写入动作"。 没错，这似乎能解决问题，而且有一些系统的架构也确实直接使用了这个思路。但这个思路在解决一致性问题的同时，又带来了新的问题：写入的性能。如果你的应用场景有非常多的写请求，那么使用这个思路之后，后续的写请求都将会阻塞在前一个请求的写操作上，导致系统整体性能急剧下降。

总的来说，我们无法找到一种能够满足分布式系统所有系统属性的分布式一致性解决方案。因此，如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。于是，一致性级别由此诞生（本节主角来了！！！！！！）：

1、强一致性

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

2、弱一致性

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

3、最终一致性

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

---

3、CAP理论

好了，前面聊了那么多分布式一致性，对概念有了一定的理解，现在可以来看关于一致性的一个重要理论了，就是大名鼎鼎的CAP理论。

想要理解CAP理论，需要了解分布式系统的3个特性，分别是

• C 一致性（C: Consistency）;
• A 可用性（A: Availability）；
• P 分区容错性（P：Partition tolerance）（最基本要求）；

CAP理论就是说，对于任意一个分布式系统，最多只能同时满足CAP中的两个特性。

 

---

以下是这三种特性的具体含义：

1、一致性

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

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

2、可用性

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

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

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

3、分区容错性

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

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

---

因此，分布式系统的类图可以这样表示。既然不能同时满足，那么就需要舍弃起码一种特性。其中的含义如下表所示：

 

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

注意：

系统架构师往往需要把精力花在如何根据业务特点在C（一致性）和A（可用性）之间寻求平衡，意思是分区容错性是一定要考虑的，其他两个特性（CA）可以找一个平衡。

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

 

---

4、BASE理论

根据现实中的分布式系统实践的总结，基于CAP理论，逐步演化成一种实用性的理论----BASE理论。

前文也提到了，现实中主要对CA两种特性进行均衡，而BASE理论就是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。

BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

 

BASE中有三要素的概念：

1、基本可用 --- Basically Available

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

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

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

2、软状态 --- Soft state

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

3、最终一致性 --- Eventually consistent

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

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。