分布式--分布式基本理论

一.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 发送sql语句让引擎(innodb)执行,引擎执行完毕记录redolog后返回执行成功(prepare)给server,server生成binlog,并把binlog写入磁盘,再下发命令提交事务.

缺陷:
网络抖动导致的数据不一致： 第二阶段中协调者向参与者发送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 接口还必须实现幂等性。