1. 分布式理论：CAP定理
CAP 理论含义是，一个分布式系统不可能同时满足一致性（C:Consistency)，可用性（A: Availability）和分区容错 性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的2个。
| 选项 | 描述 |
|---|---|
| C 一致性 | 分布式系统当中的一致性指的是所有节点的数据一致，或者说是所有副本的数据一致 |
| A 可用性 | Reads and writes always succeed. 也就是说系统一直可用，而且服务一直保持正常 |
| P 分区容错性 | 系统在遇到一些节点或者网络分区故障的时候，仍然能够提供满足一致性和可用性的服务 |
C - 如何实现一致性?
- 写入主数据库后要数据同步到从数据库
- 写入主数据库后,在向从数据库同步期间要将从数据库锁定, 等待同步完成后在释放锁,以免在写新数据后,向从数据
库查询到旧的数据.
A - 如何实现可用性?
- 写入主数据库后要将数据同步到从数据库
- 由于要保证数据库的可用性,不可以将数据库中资源锁定
- 即使数据还没有同步过来,从数据库也要返回查询数据, 哪怕是旧数据,但不能返回错误和超时
P - 如何实现分区容错性?
- 尽量使用异步取代同步操作,举例 使用异步方式将数据从主数据库同步到从数据库, 这样节点之间能有效的实现松耦合;
- 添加数据库节点,其中一个从节点挂掉,由其他从节点提供服务
CAP只能3选2
舍弃A(可用性)，保留CP(一致性和分区容错性)
一个系统保证了一致性和分区容错性，舍弃可用性。也就是说在极端情况下，允许出现系统无法访问的情况出现，这个 时候往往会牺牲用户体验，让用户保持等待，一直到系统数据一致了之后，再恢复服务。
舍弃C(一致性)，保留AP(可用性和分区容错性)
这种是大部分的分布式系统的设计，保证高可用和分区容错，但是会牺牲一致性。
舍弃P(分区容错性)，保留CA(一致性和可用性)
如果要舍弃P，那么就是要舍弃分布式系统，CAP也就无从谈起了。可以说P是分布式系统的前提，所以这种情况是不存在
2.分布式理论：BASE 理论
BASE：
- Basically Available(基本可用)
- Soft state（软状态）
- Eventually consistent（最终一致性）
1.Basically Available(基本可用)
- 响应时间上的损失：响应时间增加
- 功能损失：服务降级
2.Soft state（软状态）
允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟。
3.Eventually consistent（最终一致性）
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
3.分布式理论：一致性协议 2PC
1. 什么是2PC？
- 2 两个阶段
- p 准备阶段
- c 提交阶段
2. 2PC（二阶段提交）流程
阶段一：准备阶段
- 事务询问，协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
- 执行事务 (写本地的Undo/Redo日志)
- 各参与者向协调者反馈事务询问的响应
阶段二：提交阶段
- 发送提交请求：协调者向所有参与者发出 commit 请求。
- 事务提交：参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
- 反馈事务提交结果：参与者在完成事务提交之后，向协调者发送 Ack 信息。
- 完成事务：协调者接收到所有参与者反馈的 Ack 信息后，完成事务。
3. 2PC的缺点
- 同步阻塞：一个参与者提交阶段，只有等到所有参与者都提交了，才能做其他操作
- 单点问题：协调者挂了
- 数据不一致：commit失败
- 过于保守：参与者挂了，只能通过协调者的策略来处理
4.分布式理论：一致性协议 3PC
3PC （将2PC的“提交事务请求”分为了两步），三阶段引入超时机制。同时在协调者和参与者中都引入超时机制，参与者会在协调者超时后，自动提交事务。
1. 3pc（三阶段提交）过程
阶段一 CanCommit
- 事务询问
- 参与者反馈响应
阶段二 PreCommit
- 发送预提交请求
- 事务预提交
- 各参与者反馈结果
阶段三 DoCommit
- 发送提交请求
- 事务提交
- 反馈提交结果
- 完成事务
2.问题
相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
总结：3pc相对于2pc，添加了超时机制，precommit中保障了各个节点状态是一致的。但是，无论是2pc 还是 3pc 都无法完全解决分布式一致性的问题