分布式系统之 CAP 理论和 Base 理论
内容整理自
邴越的分布式技术原理与实战45讲，『一块钱上车传送门』。持续学习，遇见更好的自己！
一、 分布式系统
1. 集中式系统的性能问题
毕竟单台机器的性能有限，集中式架构的性能问题主要包含：
- 可用性不高，容易出现点单故障
- 可扩展性不高，水平扩展系统容量的难度较大
- 可维护性低，业务系统间的耦合程度大
- 成本高，高配置机器成本和低配置机器的成本并不是线性关系
2. 分布式系统的好处
分布式系统的核心是 可扩展性，通过多台机器的合作来完成单台机器无法完成的任务。好处是：
- 成本低，可以由多台一般配置的机器协同合作，来完成需要高配置机器才能完成的工作。
- 可用性高，多台机器同时出故障的几率要小于单台机器出故障的几率。
- 可扩展性高，理想情况下，只需要水平增加机器就可以线性增加系统容量
3. 分布式系统常见问题
由于分布式系统由多台机器协同合作来提供服务，虽然避免了 单点故障，提高了可用性，但也存在一些问题：
- 多台机器间的通信：
- 时序性
- 网络可用性
- 多台机器间的数据：
- 状态的一致性
- 同步的实时性
二、 CAP理论
1. 结论
CAP 理论指出，一个分布式系统只能同时满足以下两点：
-
Consistency一致性：所有机器同时看到相同的数据 -
Availability可用性：任何时候，读写都是成功的 -
Partition Tolerance分区容忍性：部分机器通信延迟、失败或者故障时，系统还可以继续提供一致、可用的服务
2. 结论反证
假设能够同时保证 CAP，因为 P 的存在，则一定存在部分机器间无法通信的情况，那么则一定无法保证所有机器之间的一致性。
3. CP 和 AP
由于 P 是一定的，分布式系统可分为：
- CP：牺牲一些可用性，来保证更好的一致性。如：ZooKeeper，用来解决分布式系统中多台机器的协调和一致性问题。
- AP：牺牲一些一致性，来保证更好的可用性。如：Eureka，用来在微服务系统中提供服务的注册和查询功能。
三、 Base 理论
1. 一致性分类
一致性分类：
- 强一致性：多台机器的状态，一致且实时。
- 弱一致性：多台机器的状态，在用户能够接受的时间范围内，能达到
最终一致。细分：- 因果一致性，如：会话一致性
- 单调读一致性
- 单调写一致性
2. 因果一致性举例
因果一致性是指，有因果关系的操作在顺序上能够得到保证。即：机器 A 完成了对某数据的更新，然后告知了机器 B，机器 B 必须能够读取到机器 A 更新后的数据，如果机器 B 也要更新那个数据，必须在机器 A 的更新结果上进行更新。
比如微信：你发了一个朋友圈，你的朋友进行了评论，评论动作由 A 机器来完成。此后，你又对朋友的评论进行了回复，回复动作由 B 机器来完成。这时的 评论 和 回复 就有因果关系，执行顺序必须得到保证。
3. 会话一致性举例
会话一致性是指，在一个会话中，必须 能够读到刚才写入的数据。比如：分布式系统中的 session 一致性问题。
4. Base 理论
Base 理论的核心思想是 最终一致性，简单概述就是：放弃强一致性，追求分区容错性和可用性。具体是：
- Basically Available，基本可用。
基本可用是指，不追求 任何时候读写都是成功的，而是 系统能够基本运行，一直提供服务。例如：在一些秒杀系统中，当最大 QPS 超过系统容量时，返回的 稍后再试，就是基本可用的一种表现。
- Soft State，软状态。
对比数据库中的 ACID 模型，要求操作的原子性，结果的一致性，就是一种 硬状态。而 软状态 是指，允许系统中的数据存在中间状态，并且不影响系统的整体可用性。比如：数据库集群中的同步延迟问题，我们可以接受这个延迟，多个机器间的数据短时间内的不一致，就是一种 软状态。
- Eventually Consistent，最终一致。
最终一致 是指，数据不能一直是 软状态，需要在一个能接受的时间范围内，能够达到一致性。还以数据库集群为例，我们允许同步延迟，但还是要能够 在一定时间后，集群达到一致，而这个 迟到的一致 就称为 最终一致。
5. Base 和 CAP 的关系
Base 是在 CAP 的基础上演化而来的。CAP 指出了 一致性、可用性、分区容错性，这三者只能选择两者，Base 是一种 AP 方案，即：在分区容错性一定存在的前提下，通过将强一致性退化为最终一致性的牺牲，来最求更好的可用性。
很多分布式系统都在选择 Base 理论作为架构方式，比如：NoSQL 和 微服务，强调通过服务降级等方式保证基本可用，最求更高的可扩展性，从而保证更好的可用性。而某些对数据有强一致性要求的应用，如金融系统，则应该选择 CP 思路的架构方式。
