【微服务】：分布式系统的CAP理论

[littlejoyo]

个人博客：https://joyohub.com/

微信公众号：Joyo说

• 随着分布式事务的出现，传统的单机事务模型（ACID）已经无法胜任

• 尤其是对于一个高访问量、高并发的互联网分布式系统来说，要做的改变更多

• 本文主要介绍分布式系统公认的定理————CAP理论

Github issues:https://github.com/littlejoyo/Blog/issues/

1.单机事务的ACID理论

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

Atomicity（原子性）

• 一个事务的所有操作，要么全部完成，要么全部不完成。

• 所谓事务，是指由一系列数据操作所组成的完整逻辑过程。

比如银行转账事务由两个操作组成：从源账户扣除金额，以及向目标账户增加金额。

Consistency（一致性）

• 指事务开始之前和事务结束之后，数据的完整性约束没有被破坏。

包含两层含义：

• a)数据库机制层面，事务执行前后，数据能符合设置的约束，如唯一约束、外键约束；

• b)业务层面，由应用开发人员保证业务一致性。还是以银行转账为例，A、B两个账号，转账之前和之后，A、B两个账号余额总额必须一致。

Isolation（隔离性）

• 数据库能够防止由于多个并发事务交叉执行而导致数据的不一致。

Durability（持久性）

• 指事务结束后，对数据的修改是永久的，不会回滚到之前的状态。

2.什么是CAP理论？

2.1 概念

ACID只适用于单机事务，但是在分布式系统中，ACID已经不适合应用了，因此为分布式系统提出了CAP理论。

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

2.2 CAP理论分析

Consistency 一致性

• 强调集群节点中数据的一致性

• 在分布式中一致性又包括强一致性和弱一致性，强一致性就是指在任何时刻任何节点看到的数据都是一样的；

• 弱一致性一般实现是最终一致性，即刚开始可能存在差异，但随着时间的推移，最终数据保持一致。

1、强一致性

• 最强的一致性模型，要求任何读取操作都能读取到最新的值

• 换句话说，要求任何写入操作立即同步给所有进程

2、弱一致性

• 这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致

• 但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。

3、最终一致性

• 最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。

• 这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型。

Availability 可用性

• 强调集群在任何时间内都正常使用

• 好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。

• 可用性通常情况下可用性和分布式数据冗余，负载均衡等有着很大的关联。

Partition Tolerance 分区容错性

• 即使某一部分集群坏掉，另一部分仍能正常工作。

• 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。

• 一般来说分布式集群都会保证P优先，即集群部分节点坏死不影响整个集群的使用，然后再去追求C和A。

• 因为如果放弃P——分区可用性，那不如就直接使用多个传统数据库了。

3.CAP理论证明

3.1 场景模拟

上图表示网络中有两个节点N1和N2，可以简单的理解N1和N2分别是两台计算机，他们之间网络可以连通，N1中有一个应用程序A，和一个数据库V，N2也有一个应用程序B和一个数据库V。

现在，A和B是分布式系统的两个部分，V是分布式系统的数据存储的两个子数据库。

• 在满足一致性的时候，N1和N2中的数据是一样的，V0=V0。

• 在满足可用性的时候，用户不管是请求N1或者N2，都会得到立即响应。

• 在满足分区容错性的情况下，N1和N2有任何一方宕机，或者网络不通的时候，都不会影响N1和N2彼此之间的正常运作。

3.2 分布式系统正常运转的流程

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

根据上面可以定义：

• N1和N2的数据库V之间的数据是否一样为一致性；

• 外部对N1和N2的请求响应为可用性；

• N1和N2之间的网络环境为分区容错性。

这是正常运作的场景，也是理想的场景，然而现实是残酷的，当错误发生的时候，一致性和可用性还有分区容错性，是否能同时满足，还是说要进行取舍呢？

3.3 网络调用失败情况

假设在N1和N2之间网络断开的时候，有用户向N1发送数据更新请求，那N1中的数据V0将被更新为V1

由于网络是断开的，所以分布式系统同步操作M，所以N2中的数据依旧是V0；这个时候，有用户向N2发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据V1，怎么办呢？

可供选择的做法：

1.牺牲数据一致性，响应旧的数据V0给用户；

2.牺牲可用性，阻塞等待，直到网络连接恢复，数据更新操作M完成之后，再给用户响应最新的数据V1。

这个过程，证明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。

4.CAP权衡

通过CAP理论，我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要舍弃哪个呢？

CA without P：

• 如果不要求P（不允许分区容错），则C（强一致性）和A（可用性）是可以保证的。

• 但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。

CP without A：

• 如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。

• 很多传统的数据库分布式事务都属于这种模式。

AP wihtout C：

• 保留高可用并允许分区，则需放弃一致性。

• 一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

• 现在众多的NoSQL都属于此类。

应用场景：

• 对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C（退而求其次保证最终一致性）。

• 虽然某些地方会影响客户体验，但没达到造成用户流程的严重程度。

• 对于涉及到钱财这样不能有一丝让步的场景，C必须保证。
  网络发生故障宁可停止服务，这是保证CA，舍弃P。

5.BASE理论

BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(Strong Consistency),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。

基本可用(Basically Available)

• 基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。

• 电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现。

软状态( Soft State)

什么是软状态呢？

相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。

• 软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

• 分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。

• mysql replication的异步复制也是一种体现。

最终一致性( Eventual Consistency)

• 最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。

• 弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。

BASE和ACID代表两种截然相反的设计理念，ACID注重一致性，是传统关系型数据库（MySQL）的设计思路，BASE关注高可用性。

当今大规模、跨数据中心的分布式系统（如云计算）大多同时采用这两种设计理念，并在两者之间寻求平衡。

微信公众号

扫一扫关注Joyo说公众号，共同学习和研究开发技术。