分布式理论

CAP

CAP 实际上指的是一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）。
CAP 理论指出，对于一个分布式系统，当涉及到读写操作的时候，只能满足以下三点中的两个：
- 一致性：所有节点访问同一份的最新副本。
- 可用性：非故障的节点在合理的时间返回合理的响应（不是错误或者超时）。
- 分区容错性：分布式系统出现网络分区的时候，仍然可以对外提供服务。
什么是网络分区？
- 在分布式系统中，多个节点之间的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）导致某些节点之间不再连通，整个网络就分成了几块区域，这就叫网络分区。
不是所谓的“3 选 2”
- 在发生 P（Partition Tolerance）的条件下，A（Availability）和 C（Consistency）只能满足一个，也就是分布式系统只能选择 CP 或 AP。Zookeeper 是 CP 架构，而 Nacos 不仅支持 CP 架构，也支持 AP 架构。

CAP 的实际应用案例

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。
ZooKeeper 保证的是 CP。
Eureka 保证的是 AP。
Nacos 支持 CP 也支持 AP。

BASE 理论

BASE 是 Basically Available（基本可用）、Soft-state（软状态）和 Eventually Consistent（最终一致性）的缩写。
- 基本可用：基本可用是指分布式系统在出现不可预知故障时，允许损失部分可用性。
  - 响应时间上的损失：正常情况下，处理用户请求需要 0.5s 返回结果，但由于系统出现故障，处理时间可能变为 3s。
  - 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但由于系统访问量突然剧增，部分非核心功能可能无法使用。
- 软状态
  - 软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
- 最终一致性
  - 系统中所有的数据副本在经过一段时间的同步后，最终能够达到一致的状态。因此，最终一致性的本质是系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
分布式一致性的 3 种级别
- 强一致性：系统写入了什么，读出来的就是什么。
- 弱一致性：不一定可以读取到最新写入的值，也不保证在多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
- 最终一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。
实现最终一致性的具体方式：
- 读时修复：在读取数据时，检测数据的不一致并进行修复。
- 写时修复：在写入数据时，检测数据的不一致并进行修复。
- 异步修复：最常用的方式，通过定时对账检测副本数据的一致性，并修复。
核心思想：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点就是 BASE 理论延伸的地方。

ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。

分布式算法

Paxos 算法

Basic Paxos 中存在 3 个重要的角色：
- 提议者（Proposer）：也可以叫做协调者（coordinator），提议者负责接受客户端的请求并发起提案。提案信息通常包括提案编号（Proposal ID）和提议的值（Value）。
- 接受者（Acceptor）：也可以叫做投票员（voter），负责对提议者的提案进行投票，同时需要记住自己的投票历史。
- 学习者（Learner）：如果有超过半数接受者就某个提议达成了共识，学习者就需要接受这个提议，并就该提议作出运算，然后将运算结果返回给客户端。
Multi Paxos 思想
- Basic Paxos 算法仅能就单个值达成共识，为了能够对一系列的值达成共识，我们需要用到 Multi Paxos 算法。
Paxos 思想