为什么要分布式

分布式是为了解决传统单点零碎 性能低 、 可用性低 、 扩展性低 的问题

基于分布式的指标，能够把分布式系统进行分类：

• 为了进步性能，应答高并发，海量数据处理，此类零碎代表：无状态的微服务、分布式数据等
• 为了进步可用性，防止单点故障，同时保证数据的一致性，此类零碎代表：注册核心、集群协调器等

这里 只探讨后者，为了进步可用性，某些要害利用须要集群部署，同时还要保障所有节点数据的一致性。

2PC（Two-phase Commit）

在分布式系统中，每个节点尽管能够通晓本人的操作时胜利或者失败，却无奈晓得其余节点的操作的胜利或失败。当一个事务逾越多个节点时，为了放弃事务的 ACID 个性，须要引入一个作为 协调者 的组件来对立掌控所有节点（称作 参与者 ）的操作后果并最终批示这些节点是否要把操作后果进行真正的提交（比方将更新后的数据写入磁盘等等）。因而，二阶段提交的算法思路能够概括为： 参与者将操作成败告诉协调者，再由协调者依据所有参与者的反馈情报决定各参与者是否要提交操作还是停止操作

2PC 前提

1. 该分布式系统中，存在一个节点作为 协调者 （Coordinator），其余节点作为 参与者（Participants）。且节点之间能够进行网络通信。
2. 所有节点都采纳预写式日志（redo undo log），且日志被写入后即被放弃在牢靠的存储设备上，即便节点损坏不会导致日志数据的隐没。
3. 所有节点不会永久性损坏，即便损坏后依然能够复原。

算法实现

第一阶段（提交申请阶段）

1. 协调者向所有参与者节点是否能够执行提交操作，并期待各节点的响应。
2. 各参与者执行协调者发动的事务，并写入undo 和 redo Log。
3. 各参与者响应协调者发动的询问。若事务操作执行胜利，则返回‘批准’，若执行失败，则返回一个‘终止’信息。

第二阶段（提交执行阶段）

胜利（各参与者均返回批准）

1. 协调者向所有参与者发动“正式提交”申请。
2. 参与者正式实现操作，并开释事务所占的资源(次要是锁)。
3. 参与者向协调者发送“实现事务”告诉。
4. 协调者收到各参与者的“实现”告诉之后，实现事务。

失败（任意节点返回终止，或超时未返回）

1. 协调者向所有参与者发动“回滚”申请。
2. 参与者利用之前记录的 undo 日志，进行回滚。
3. 参加则会告诉协调者，回滚胜利。
4. 协调者收到回滚胜利音讯之后，勾销事务。

算法示意

算法劣势

• 提交性能由参与者中最慢的节点决定，往往较慢。
• 无奈提交阶段若有节点失联，无奈解决。

• 一旦做出决定就无奈撤销。

  • 参与者不管是否提交，在响应协调者之后，必须持有资源，期待协调者告诉。
  • 协调者一旦决定提交，则所有参与者必须提交，若有节点临时失联，也须要期待节点复原之后进行提交。