分布式的基石--一致性和共识(一)

为什么要分布式

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

基于分布式的目标，可以把分布式系统进行分类：

• 为了提高性能，应对高并发，海量数据处理，此类系统代表：无状态的微服务、分布式数据等
• 为了提高可用性，避免单点故障，同时保证数据的一致性，此类系统代表：注册中心、集群协调器等

这里只讨论后者，为了提高可用性，某些关键应用需要集群部署，同时还要保证所有节点数据的一致性。

2PC（Two-phase Commit）

2PC前提

1. 该分布式系统中，存在一个节点作为协调者（Coordinator），其他节点作为参与者（Participants）。且节点之间可以进行网络通信。
2. 所有节点都采用预写式日志 （redo undo log），且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。
3. 所有节点不会永久性损坏，即使损坏后仍然可以恢复。

算法实现

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

1. 协调者向所有参与者节点是否可以执行提交操作，并等待各节点的响应。
2. 各参与者执行协调者发起的事务，并写入undo 和 redo Log。
3. 各参与者响应协调者发起的询问。若事务操作执行成功，则返回‘同意’，若执行失败，则返回一个‘终止’信息。

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

成功（各参与者均返回同意）

1. 协调者向所有参与者发起 “正式提交” 请求。
2. 参与者正式完成操作，并释放事务所占的资源(主要是锁)。
3. 参与者向协调者发送“完成事务”通知。
4. 协调者收到各参与者的“完成”通知之后，完成事务。

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

1. 协调者向所有参与者发起“回滚”请求。
2. 参与者利用之前记录的undo日志，进行回滚。
3. 参与则会通知协调者，回滚成功。
4. 协调者收到回滚成功消息之后，取消事务。

算法示意

算法劣势

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

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

  • 参与者不论能否提交，在响应协调者之后，必须持有资源，等待协调者通知。
  • 协调者一旦决定提交，则所有参与者必须提交，若有节点暂时失联，也需要等待节点恢复之后进行提交。