分布式系统CAP理论初探

最新推荐文章于 2022-04-30 09:14:18 发布

阿飞算法

最新推荐文章于 2022-04-30 09:14:18 发布

阅读量326

点赞数 1

分类专栏： BigData 分布式文章标签：分布式

本文链接：https://blog.csdn.net/wat1r/article/details/119342154

版权

BigData 同时被 2 个专栏收录

10 篇文章 1 订阅

订阅专栏

分布式

5 篇文章 0 订阅

订阅专栏

背景

CAP定理（CAP theorem）又被称作布鲁尔定理（Brewer’s theorem），是加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在2000年的ACM PODC上提出的一个猜想。2002年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了布鲁尔猜想的证明，使之成为分布式计算领域公认的一个定理。对于设计分布式系统的架构师来说，CAP是必须掌握的理论。

概念

Consistency(一致性)

where all nodes see the same data at the same time.

更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，所以，一致性，说的就是数据一致性
对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
一致性一般在并发读写的时候才出现这个问题，需要结合并发读写的场景考虑

请添加图片描述

如上图中的pic A :客户端向N1节点发起写操作，将V0修改为V1，在接下来的读操作中，从N1节点拿到的应该是V1，这便是一致性，在单节点，这没什么问题，在分布式系统中，问题来了，从N2节点得到的结果是V0，这个值还是原来的老的值。
如上图的pic B:客户端在向N1节点发起写操作时，N1节点向N2节点发起同步操作，将两个节点的值都修改为V1，N2节点覆盖了旧值V0，这时客户端从N2节点获得的结果便是新值V1，保持了一致性。

Availability(可用性)

which guarantees that every request receives a response about whether it succeeded or failed.

对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应，不论该请求是成功或失败
如上图的结果，不论数据有没有保持一致性，客户端发起请求必然得到一个结果，不论这个结果是我们认为的正确与否，或者干脆请求是成功还是失败了
一般在描述一个系统的可用性时，可以通过停机时间来计算

请添加图片描述

我们说淘宝的系统可用性可以达到5个9，意思就是说他的可用水平是99.999%，即全年停机时间不超过 (1-0.99999)*365*24*60 = 5.256 min

Partition tolerance(分区容错性)

where the system continues to operate even if any one part of the system is lost or fails.

分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。
如上图pic B，如果N1节点和N2节点的通信因为网络通信等原因失败了，N1和N2可能位于不同的区域，我们管这种叫分区(Partition)

分布式系统设计的原则

通过复制来提高可用性

按复制的类型可以分为主动复制和被动复制

主动复制

在主动复制中，每个客户端请求都由所有服务器处理，要求服务器托管的服务是确定性的
确定性意味着，给定相同的初始状态和请求序列，所有过程将产生相同的响应序列，并且最终处于相同的最终状态。为了使所有的服务器接收到相同的操作序列，一般都使用原子广播协议。原子广播协议保证所有服务器都接收到消息或没有消息，并且它们都以相同的顺序接收消息。
主动复制的主要缺点是实际上大多数真实世界的服务器都是非确定性的。

被动复制

只有一个服务器（称为主服务器）处理客户机请求。处理请求后，主服务器更新其它（备份）服务器上的状态，并将响应发送回客户端。如果主服务器发生故障，则其中一台备份服务器就会接管它。被动复制可以用于非确定性过程。
被动复制与主动复制相比的主要缺点是在失败的情况下，客户端的响应会被延迟。

从进程与系统交互角度来看，复制分为同步复制和异步复制

同步复制

通过原子写入操作来保证“零数据丢失”，即完全写入。在本地和远程副本存储的确认之前，写入不被认为是完整的。

异步复制

本地存储确认后，写入即被认为是完整的。远程存储已更新，但可能滞后很小。系统性能会因异步复制而大大提高。但在丢失本地存储的情况下，远程存储不能保证具有当前的数据副本，并且最近的数据可能会丢失。

请添加图片描述

CAP的理论证明

在这里插入图片描述

如下图，N1节点上有应用程序A和数据库V，N2节点上有应用程序B和数据库V，A和B是分布式系统的两个部分，V是分布式系统的数据存储的两个子数据库，N1节点和N2节点在不同的分区，但是可以通过网络进行通信
- 在满足一致性的时候，N1和N2中的数据是一样的，V0=V0。
- 在满足可用性的时候，用户不管是请求N1或者N2，都会得到立即响应。
- 在满足分区容错性的情况下，N1和N2有任何一方宕机，或者网络不通的时候，都不会影响N1和N2彼此之间的正常运作

请添加图片描述

如上图，是分布式系统正常运转的流程，用户向N1机器请求数据更新，程序A更新数据库V0为V1，分布式系统将数据进行同步操作M，将V1同步的N2中V0，使得N2中的数据V0也更新为V1，N2中的数据再响应N2的请求

请添加图片描述

假设在N1和N2之间网络出现通信故障，有用户向N1发送数据更新请求，那N1中的数据V0将被更新为V1，由于网络是异常的，所以分布式系统同步操作sync，所以N2中的数据依旧是V0；这个时候，有用户向N2发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据V1，怎么办呢？
有二种选择
- 第一，牺牲数据一致性，保证可用性。响应旧的数据V0给用户。
- 第二，牺牲可用性，保证数据一致性。阻塞等待，直到网络连接恢复，数据更新操作sync完成之后，再给用户响应最新的数据V1。
- 这个过程，证明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。

C and P without A

为了保证数据Consistency(一致性)，N1节点需要将数据复制给N2，即N1和N2需要进行通信。但是由于网络是不可靠的，我们系统有保证了Partition tolerance(分区容错性)，也就是说这个系统是可以容忍网络的不可靠的。这时候N2就不一定能及时的收到N1的数据同步消息，当有请求向N2访问V1数据时，为了保证数据的一致性，N2只能阻塞等待数据真正同步完成后再返回，这时候就没办法保证高Availiablity(可用性)了

A and P without C

为了保证Availiablity（可用性），N1和N2都有在有限时间内返回（及时返回数据）。同样由于网络的不可靠，在有限时间内，N2有可能还没收到N1发来的数据更新消息，这里满足了Partition tolerance(分区容错性)，这时候返回给客户端的可能是旧的数据（V0），和访问N1的数据（V1）是不一致的，也就是违反了Consistency(一致性)

C and A without P

如果要保证Availiablity（可用性）和Consistency(一致性)，只有在网络情况良好且可靠的情况下才能实现。这样N1才能立即将更新消息发送给N2。但是我们都知道网络是不可靠的，是会存在丢包的情况的。所以要满足即时可靠更新，只有将N1和N2放到一个区内才可以，也就丧失了Partition tolerance(分区容错性)这个保证。其实这时候整个系统也不能算是一个分布式系统了

CAP与ACID和BASE等比较

ACID

原子性（Atomicity）：要么全部完成，要么全部失败
一致性（Consistency）：事务开始和完成时，数据必须保持一致的状态，数据库的完整性约束没有被破坏。比如A给B转账，不论转账事务是否成功，两者存款的总额不变
隔离性（Isolation）：多个事务并发访问时，事务之间是隔离的，一个事务不能影响到其他事务的结果，不能看到其他事务运行时中间某个时刻的数据。
持久性（Durability）：事务完成后，该事务对数据库所作的更改便持久地保存在数据库中，并不会被回滚

BASE

BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。

基本可用（Basically Available）

分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
这里的关键词是“部分”和“核心”，具体选择哪些作为可以损失的业务，哪些是必须保证的业务，是一项有挑战的工作。例如，对于一个用户管理系统来说，“登录”是核心功能，而“注册”可以算作非核心功能。因为未注册的用户本来就还没有使用系统的业务，注册不了最多就是流失一部分用户，而且这部分用户数量较少。如果用户已经注册但无法登录，那就意味用户无法使用系统。例如，充了钱的游戏不能玩了、云存储不能用了……这些会对用户造成较大损失，而且登录用户数量远远大于新注册用户，影响范围更大。

软状态（Soft State）

允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是CAP理论中的数据不一致。

最终一致性（Eventual Consistency）

系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
这里的关键词是“一定时间” 和 “最终”，“一定时间”和数据的特性是强关联的，不同的数据能够容忍的不一致时间是不同的。举一个微博系统的例子，用户账号数据最好能在1分钟内就达到一致状态，因为用户在A节点注册或者登录后，1分钟内不太可能立刻切换到另外一个节点，但10分钟后可能就重新登录到另外一个节点了；而用户发布的最新微博，可以容忍30分钟内达到一致状态，因为对于用户来说，看不到某个明星发布的最新微博，用户是无感知的，会认为明星没有发布微博。“最终”的含义就是不管多长时间，最终还是要达到一致性的状态。