一.CAP 定理:
Consistency 一致性
同一个数据的所有备份，在同一时刻是否有雷同的值。一种比拟常见的强一致性实现就是，在看到统一的后果之前，写申请不返回，读申请阻塞或者超时
Availability 可用性
在集群中一些节点故障时，集群还能够响应读写申请
Partition-tolerance 分区容忍性
分布式系统具备多个节点，如果节点间网络中断，就会造成分区
CA 零碎
不容许分区(也就只能单机零碎了), 例如单机数据库 mysql
CP 零碎
不要求高可用, 但要求强一致性. 并且节点间传输数据失落导致未同步,要么重试, 要么更新失败, 回滚数据, 例如 Paxos,2PC,3PC,RAFT 等
AP 零碎
要求高可用, 不必强一致性. 产生分区时, 节点间的数据可能不统一, 每个节点用本人的本地数据提供服务. 个别该类零碎都会实现最终一致性, 即分区完结后, 通过一些机制同步数据.
二.BASE 实践
BASE 实践是 Basically Available(根本可用)，Soft State（软状态）和 Eventually Consistent（最终一致性）三个短语的缩写。
BA 根本可用
- 响应工夫上的损失：失常状况下的搜索引擎 0.5 秒即返回给用户后果，而根本可用的搜索引擎能够在 2 秒作用返回后果。
- 性能上的损失：在一个电商网站上，失常状况下，用户能够顺利完成每一笔订单。然而到了大促期间，为了爱护购物零碎的稳定性，局部消费者可能会被疏导到一个降级页面。
S 软状态
容许零碎中的数据存在中间状态，并认为该状态不影响零碎的整体可用性，即容许零碎在多个不同节点的数据正本存在数据延时。
E 最终一致性
存在一个期限, 在期限过后，该当保障所有正本保持数据一致性，从而达到数据的最终一致性
三.2PC 协定
第一阶段：筹备阶段（投票阶段）
第二阶段：提交阶段（执行阶段）
如 mysql server 记录 binlog 后 发送 sql 语句让引擎 (innodb) 执行, 引擎执行结束记录 redolog 后返回执行胜利给 server,server 再下发命令提交事务.
缺点:
网络抖动导致的数据不统一：第二阶段中协调者向参与者发送 commit 命令之后，一旦此时产生网络抖动，导致一部分参与者接管到了 commit 申请并执行，可其余未接到 commit 申请的参与者无奈执行事务提交。进而导致整个分布式系统呈现了数据不统一。
超时导致的同步阻塞问题：2PC 中的所有的参与者节点都为事务阻塞型，当某一个参与者节点呈现通信超时，其余参与者都会被动阻塞占用资源不能开释。
单点故障的危险：因为重大的依赖协调者，一旦协调者产生故障，而此时参与者还都处于锁定资源的状态，无奈实现事务 commit 操作。尽管协调者呈现故障后，会从新选举一个协调者，可无奈解决因前一个协调者宕机导致的参与者处于阻塞状态的问题。
四.3PC
CanCommit：协调者向所有参与者发送 CanCommit 命令，询问是否能够执行事务提交操作。如果全副响应 YES 则进入下一个阶段
PreCommit：协调者向所有参与者发送 PreCommit 命令，询问是否能够进行事务的预提交操作，参与者接管到 PreCommit 申请后，如参与者胜利的执行了事务操作，则返回 Yes 响应，进入最终 commit 阶段。一旦参与者中有向协调者发送了 No 响应，或因网络造成超时，协调者没有接到参与者的响应，协调者向所有参与者发送 abort 申请，参与者承受 abort 命令执行事务的中断。
DoCommit：在前两个阶段中所有参与者的响应反馈均是 YES 后，协调者向参与者发送 DoCommit 命令正式提交事务，如协调者没有接管到参与者发送的 ACK 响应，会向所有参与者发送 abort 申请命令，执行事务的中断。
三段提交（3PC）是对两段提交（2PC）的一种降级优化，3PC 在 2PC 的第一阶段和第二阶段中插入一个筹备阶段。保障了在最初提交阶段之前，各参与者节点的状态都统一。同时在协调者和参与者中都引入超时机制，当参与者各种起因未收到协调者的 commit 申请后，会对本地事务进行 commit，不会始终阻塞期待，解决了 2PC 的单点故障问题，但 3PC 还是没能从根本上解决数据一致性的问题。
五.TCC
TCC（Try-Confirm-Cancel）又被称弥补事务，TCC 与 2PC 的思维很类似，事务处理流程也很类似，但 2PC 是利用于在 DB 层面，TCC 则能够了解为在利用层面的 2PC，是须要咱们编写业务逻辑来实现。
TCC 它的核心思想是：” 针对每个操作都要注册一个与其对应的确认（Try）和弥补（Cancel）”。
还拿下单扣库存解释下它的三个操作：
Try 阶段：
下单时通过 Try 操作去扣除库存预留资源。
Confirm 阶段：
确认执行业务操作，在只预留的资源根底上，发动购买申请。
Cancel 阶段：
只有波及到的相干业务中，有一个业务方预留资源未胜利，则勾销所有业
TCC 的毛病：
利用侵入性强：TCC 因为基于在业务层面，至使每个操作都须要有 try、confirm、cancel 三个接口。
开发难度大：代码开发量很大，要保证数据一致性 confirm 和 cancel 接口还必须实现幂等性。