【温故而知新】分布式系统（二）
分布式系统的 CAP 理论
时间：2022年12月12日
作者：小蒋聊技术
【温故而知新】分布式系统（二）·分布式系统的 CAP 理论_小蒋聊技术_免费在线阅读收听下载 - 喜马拉雅手机版欢迎收听小蒋聊技术的其他类最新章节声音“【温故而知新】分布式系统（二）·分布式系统的 CAP 理论”。
https://m.ximalaya.com/sound/596020220?from=pc
前言
大家好，欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。
今天小蒋继续坚持“温故而知新”的落地实践，准备和大家聊一聊“分布式系统的 CAP 理论”。
小蒋个人认为，对于分布式系统的参与者来说，CAP 是必须要掌握的基础理论之一，CAP 理论可以帮助我们对系统设计中的目标进行取舍，合理地规划系统拆分的维度。
CAP理论作为分布式系统的基石，小蒋将和大家一起来复习一遍。
分布式系统的特点
既然CAP是分布式系统的基石，咱们得先来看看分布式系统，以及分布式系统它的特点。
分布式系统是多个服务器通过网络互联而构建的松耦合系统，其具备以下特点：
- 分布式：分布式由多台计算机组成，在地域上是独立分散的，可以分散在一个单位，一个城市，一个国家，或是全球范围内。整个系统的统一功能是分散在多个节点上实现的，因而分布式系统具有数据处理的分布式特性。
- 自治性：分布式系统各个节点包含自己独有的cpu和内存，具备独立的处理数据能力。一般来说每个节点是对等的，没有主次之分，可以自治的进行任务处理，还可以通过网络传输信息，协同完成任务处理。
- 并行性：一个大的任务可以按规则划分到多个计算节点上进行独立的子任务支持，体现了并行性。
- 全局性：分布式系统必须存在一个单一的，全局的通信机制，使得任何一个进程都能和其他进程通信，并且不区分本地通信和远程通信。在一个分布式集群中，往往所有机器具有统一的系统调用能力。
在不同的抽象层次上来说，分布式系统中每一个物理机，虚拟机，docker镜像，等等，独立进程都可以认为是一个节点。
分布式系统的核心理念是让多台服务器协同工作，完成单台服务器无法处理的任务，尤其是高并发或者大数据量的任务。除了对可扩展性的需求，分布式系统还有不出现单点故障、提供服务或者存储无状态等特点。
- 单点故障（Single Point Failure）：是指在系统中某个组件一旦失效，这会让整个系统无法工作。而不出现单点故障，这意味着单点不影响整体，就是分布式系统的设计目标之一；
- 无状态（Stateless）：是因为无状态的服务才能满足部分机器宕机不影响全部，可以随时进行扩展的需求。 由于分布式系统的特点，在分布式环境中更容易出现问题，比如节点之间通信失败、网络分区问题、多个副本的数据不一致问题等，为了更好地在分布式系统下进行开发，学者们提出了一系列的理论，其中具有代表性的就是 CAP 理论。
| 2000年7月，加州大学伯克利分校的Eric Brewer（埃里克 布鲁尔）教授在ACM PODC（分布式计算原理会议）会议上提出CAP猜想。2年后,也就是2002年，麻省理工学院的Seth Gilbert（赛斯 吉尔伯特）和Nancy Lynch（南希 林奇）从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域的公认定理。 |
CAP理论概述
维基百科地址：https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
一·Consistency 一致性
一致性指“all nodes see the same data at the same time”，即所有节点在同一时间的数据完全一致。
一致性是因为多个数据拷贝下并发读写才有的问题，因此理解时一定要注意结合考虑多个数据拷贝下并发读写的场景。
对于一致性，可以分为从客户端和服务端两个不同的视角分析。
- 客户端
从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。
- 服务端
从服务端来看，则是更新如何分布到整个系统，以保证数据最终一致。
对于一致性，可以分为强/弱/最终一致性三类。
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。
- 强一致性
对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。
- 弱一致性
如果能容忍后续的部分或者全部访问不到，则是弱一致性。
- 最终一致性
如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
二·Availability 可用性
可用性指“Reads and writes always succeed”，即服务在正常响应时间内一直可用。
好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。可用性通常情况下和分布式数据冗余，负载均衡等有着很大的关联。
我们可以看到一些IT公司对外宣传，系统稳定性已经做到 3 个 9、4 个 9，即 99.9%、99.99%，这里的 N 个 9 就是对可用性的一个描述，叫做 SLA，即服务水平协议。
比如说月度 99.95% 的 SLA，则意味着每个月服务出现故障的时间只能占总时间的 0.05%，如果这个月是 30 天，那么就是 21.6 分钟。
三·Partition Tolerance分区容错性
分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。
在分布式系统中根据其特点，P其实是确定的，CAP 的应用模型就是 CP 架构和 AP 架构。分布式系统所关注的，就是在 Partition Tolerance 的前提下，如何实现更好的 A 和更稳定的 C。
CAP 理论的证明
CAP 理论的证明有多种方式，通过反证的方式小蒋个人认为是比较直观的。反证法来证明 CAP 定理，最早是由 Lynch （林奇）提出的，通过一个实际场景，如果 CAP 三者可同时满足，由于允许 P 的存在，则一定存在 Server 之间的丢包，如此则不能保证 C。
首先构造一个单机系统，如上图，Client A 可以发送指令到 Server 并且设置更新 X 的值，Client 1 从 Server 读取该值，在单点情况下，即没有网络分区的情况下，通过简单的事务机制，可以保证 Client 1 读到的始终是最新值，不存在一致性的问题。
我们在系统中增加一组节点，因为允许分区容错，Write 操作可能在 Server 1 上成功，在 Server 2 上失败，这时候对于 Client 1 和 Client 2，就会读取到不一致的值，出现不一致的情况。如果要保持 X 值的一致性，Write 操作必须同时失败， 也就是降低系统的可用性。 可以看到，在分布式系统中，无法同时满足 CAP 定律中的“一致性”“可用性”和“分区容错性”三者。 在该证明中，对 CAP 的定义进行了更明确的声明：
- Consistency，一致性，被称为原子对象，任何的读写都应该看起来是“原子”的，或串行的，写后面的读一定能读到前面写的内容，所有的读写请求都好像被全局排序；
- Availability，可用性，对任何非失败节点都应该在有限时间内给出请求的回应（请求的可终止性）；
- Partition Tolerance，分区容错性，允许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会完全丢失。
CAP 理论的应用
CAP 理论提醒我们，在架构设计中，不要把精力浪费在如何设计能满足三者的完美分布式系统上，而要合理进行取舍，CAP 理论类似数学上的不可能三角，只能三者选其二，不能全部获得。
不同业务对于一致性的要求是不同的。举个例来讲，在微博上发表评论和点赞，用户对不一致是不敏感的，可以容忍相对较长时间的不一致，只要做好本地的交互，并不会影响用户体验；
而我们在电商购物时，产品价格数据则是要求强一致性的，如果商家更改价格不能实时生效，则会对交易成功率有非常大的影响。
需要注意的是，CAP 理论中是忽略网络延迟的，也就是当事务提交时，节点间的数据复制一定是需要花费时间的。即使是同一个机房，从节点 A 复制到节点 B，由于现实中网络不是实时的，所以总会有一定的时间不一致。
总结
在通常的分布式系统中，为了保证数据的高可用，通常会将数据保留多个副本（Replica），网络分区是既成的现实，于是只能在可用性和一致性两者间做出选择。CAP 理论关注的是在绝对情况下，在工程上，可用性和一致性并不是完全对立的，我们关注的往往是如何在保持相对一致性的前提下，提高系统的可用性。 业务上对一致性的要求会直接反映在系统设计中，典型的就是 CP 和 AP 架构的取舍。
- CP 架构：对于 CP 来说，放弃可用性，追求一致性和分区容错性。
我们熟悉的 ZooKeeper，就是采用了 CP 模式，ZooKeeper 是一个分布式的服务框架，主要用来解决分布式集群中应用系统的协调和一致性问题。其核心算法是 ZAB(ZooKeeper Atomic Broadcast)，它是是为ZooKeeper设计的一种支持崩溃恢复的原子广播协议，所有设计都是为了一致性。
在 CAP 模型中，ZooKeeper 是 CP，这意味着面对网络分区时，为了保持一致性，它是不可用的。
- AP 架构：对于 AP 来说，放弃强一致性，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的 Base 也是根据 AP 来扩展的。
和 ZooKeeper 相对的是 Eureka，Eureka 是 Spring Cloud 微服务技术栈中的服务发现组件，Eureka 的各个节点都是平等的，几个节点挂掉不影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，只要有一台 Eureka 还在，就能保证注册服务可用，只不过查到的信息可能不是最新的版本，不保证一致性。
以上，就是今天小蒋要跟大家分享的全部内容。
年龄的增长不可怕，可怕的是从未成长！
感谢大家支持小蒋，小蒋希望和大家共同成长，谢谢。