一、CAP定理
CAP定理：一个分布式系统不可能同时满足一致性（C:Consistency)，可用性（A: Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的2个。而分区容忍性（P）必须要实现，所以我们多数情况下需要在一致性（C）和可用性（A）之间进行权衡。要么是CP，要么是AP。
| 属性 | 具体描述 |
|---|---|
| C（Consistence） | 一致性，指数据在多个副本之间能够保持一致的特性（严格的一致性）。 |
| A（Availability） | 可用性，指系统提供的服务必须一直处于可用的状态，每次请求都能获取到正确的响应——但是不保证获取的数据为最新数据。 |
| P（Network partitioning | 分区容错性，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。 |
具体参考我之前总结过笔记： 分布式系统CAP原则
二、Base-理论
由CAP定力我们知道CAP只能取其二，其中分区容忍性（P）必须要实现，我们需要在一致性（C）和可用性（A）之间进行权衡。为了使系统尽量能够达到 CAP，于是有了 BASE 协议，而 BASE 协议是在可用性和一致性之间做的取舍和妥协。
BASE全称：Basically Available(基本可用)，Soft state（软状态）和 Eventually consistent（最终一致性）
核心思想：既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
Basically Available(基本可用)
分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
- 响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的搜索引擎可以在 1 秒作用返回结果。
- 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面，只提供降级服务。
Soft state（软状态）
硬状态：要求多个节点的数据副本都是一致的。
软状态：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
Eventually consistent（最终一致性）
软状态可以存在数据延时，但必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限视实际情况而定。
总结
总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。
ACID，指数据库事务正确执行的四个基本要素的缩写。参考什么是ACID 事务管理（ACID）
- Atomic（原子性）：原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
- Consistency（一致性）：指数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。例如对银行转帐事务，不管事务成功还是失败，应该保证事务结束后ACCOUNTS表中Tom和Jack的存款总额为2000元。
- Isolation（隔离性）：隔离性是指多个用户并发访问数据库时，数据库为每一个用户开启的事务不能被其他事物的操作所干扰，多个并发事务之间要相互隔离。即在事务提交之前对其他事务不可见。
- Durability（持久性）：只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。
三、一致性协议之-2PC&3PC
参考分布式理论（三）——-一致性协议之-2PC 分布式系统那些事-2PC和3PC协议 分布式一致性算法2PC，3PC和经典的paxos 分布式系统那些事-2PC和3PC协议
2PC
2PC协议是一种一致性协议，用来保证分布式系统数据一致性。
如果想让分布式部署的多台机器中的数据保持一致性，那么就要保证在所有节点的数据写操作，要不全部都执行，要么全部的都不执行。但是，一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果。所以他也就不知道本次事务到底应该commit还是 roolback。所以，常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。
2PC——Two-Phase Commit——二阶段提交协议，主要目的是为了保证分布式系统数据的一致性。二阶段提交就是讲事务的提交过程分成了两个阶段来进行处理。
阶段一：提交事务请求
1、事务询问（协调者 --> 参与者）
协调者向所有的参与者询问，是否准备好了执行事务，并开始等待各参与者的响应。
2、执行事务（参与者）
各参与者节点执行事务操作，并将 Undo 和 Redo 信息记入事务日志中。
3、返回对事务询问的响应（参与者 --> 协调者）
- 如果参与者成功执行了事务操作，那么就反馈给协调者 Yes 响应，表示事务可以执行；
- 如果参与者没有成功执行事务，就返回 No 给协调者，表示事务不可以执行。
阶段二：执行事务提交
两种情况：
- 所有参与者均反馈YES时，即提交事务。
- 任何一个参与者反馈NO时，即中断事务。
提交事务：（所有参与者均反馈YES）
- 协调者向所有参与者发出正式提交事务的请求（即Commit请求）。
- 参与者执行Commit请求，并释放整个事务期间占用的资源。
- 各参与者向协调者反馈Ack完成的消息。
- 协调者收到所有参与者反馈的Ack消息后，即完成事务提交。
中断事务：（任何一个参与者反馈NO或者超时）
- 协调者向所有参与者发出回滚请求（即Rollback请求）。
- 参与者使用阶段1中的Undo信息执行回滚操作，并释放整个事务期间占用的资源。
- 各参与者向协调者反馈Ack完成的消息。
- 协调者收到所有参与者反馈的Ack消息后，即完成事务中断。
总结
2PC核心是对每个事务都采用先尝试后提交的处理方式。
优点：原理简单，实现方便
缺点：同步阻塞，单点问题，数据不一致，过于保守
- 同步阻塞：各个参与者在等待其他参与者响应的过程中，无法进行其他操作，限制了分布式系统的性能。
- 单点问题：协调者是2PC的核心，如果协调者出现问题，那么整个流程将无法运转，更重要的是：其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。
- 数据不一致：假设当协调者向所有的参与者发送 commit请求时发生网络错误或者自身崩溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。
- 过于保守：任何一个参与者出现问题，都会发生回滚
为了弥补二阶段提交的缺点，研究者们在它的基础上，提出了三阶段提交。
3PC
3PC——Three-Phase Commit——三阶段提交协议。
与2PC不同的是，3PC有两个改动点：
- 引入超时机制。同时在协调者和参与者中都引入超时机制。
- 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
3PC 将2PC的阶段一分成了2部分，总共形成了 3 个部分：canCommit、preCommit、doCommit。带来的优势是阶段１和阶段２任一个出现问题协调者都可以直接中断事务，提高效率（协调者可以在阶段2、3执行中断事务）。
阶段一：canCommit
协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
1、事务询问
协调者向参与者发送canCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
2、响应反馈
参与者接到canCommit请求之后，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态，否则反馈No。
阶段二：preCommit
协调者根据参与者的响应来决定是否可以进行事务的PreCommit操作。两种情况：
执行事务预提交（所有参与者均反馈YES）
1、发送预提交请求（协调者–>参与者）：协调者向参与者发送preCommit请求，并进入prepared阶段。
2、事务预提交（参与者）：参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。
3、响应反馈（参与者–>协调者）：如果参与者成功的执行了事务操作，则返回Ack响应，同时开始等待最终指令：Commit或Abort。
中断事务（任何一个参与者反馈NO或超时）
1、发送中断请求（协调者–>参与者）：协调者向所有参与者发送Abort请求。
2、中断事务（参与者）：参与者收到来自协调者的Abort请求或是超时都会中断事务。
阶段三：doCommit
该阶段做真正的提交，也分两种情况，对应阶段二的两种情况
执行提交
1、发送提交请求（协调者–>参与者）：如果协调者接收到参与者发送的Ack响应，那么协调者将从预提交状态进入到提交状态，并向所有参与者发送doCommit请求。
2、事务提交（参与者）：参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
3、响应反馈（参与者–>协调者）：事务提交完之后，向协调者发送Ack响应。
4、完成事务（协调者）：协调者接收到所有参与者的Ack响应之后，完成事务。
中断事务（任何一个参与者反馈NO或超时）
1、发送中断请求（协调者–>参与者）：协调者向所有参与者发送Abort请求。
2、事务回滚（参与者）：参与者接收到Abort请求之后，利用其在阶段二记录的Undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
3、反馈结果（参与者–>协调者）：参与者完成事务回滚之后，向协调者发送Ack消息
4、中断事务（协调者）：协调者接收到参与者反馈的Ack消息之后，中断事务。
在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。
2PC与3PC的区别
相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。
但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
