一.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 接口还必须实现幂等性。