分布式系统中的事务恢复

使用分布式事务处理可以有效地执行事务。但是，在某些情况下，交易可能由于各种原因而失败。系统故障、硬件故障、网络错误、数据不准确或无效、应用程序问题，都是可能的原因。交易失败是无法避免的。这些故障必须由分布式事务系统处理。当出现错误时，必须能够识别和纠正错误。事务恢复是此过程的名称。在分布式数据库中，最困难的过程是恢复。恢复发生故障的通信网络系统是极其困难的。

让我们考虑以下场景来分析事务失败是如何发生的。假设，我们有两个人 X 和 Y。X 向 Y 发送消息并期望得到响应，但 Y 无法接收。

以下是这种情况下的一些问题：

• 由于网络问题，消息未发送。
• 位置 B 发送的通信未传递到位置 A。
• 地点 B 被摧毁。
• 因此，在大型通信网络中定位问题的根源极具挑战性。

网络中的分布式提交是另一个可能对分布式数据库的恢复造成严重破坏的主要问题。

事务恢复最著名的方法之一是“两阶段提交协议”。协调者和从属节点是两阶段提交协议用来完成其程序的两种类型的节点。协调者的流程链接到用户应用程序，形成下属与协调者之间的沟通渠道。

顾名思义，两阶段提交协议包含两个阶段。第一步是 PREPARE 阶段，在该阶段事务的协调器传递 PREPARE 消息。第二步是决策阶段，如果所有节点都可以完成事务，协调者发送 COMMIT 消息，如果至少有一个从属节点不能完成，则发送 abort 消息。集中式 2PC、线性 2PC 和分布式 2PC 都是可用于执行 2PC 的方式。

• 集中式2PC：集中式2PC中的联系仅限于协调者的进程，不允许下属之间的通信。协调者负责将准备消息发送给下属，一旦收到并分析了所有下属的投票，协调者就会选择是中止还是提交。此方法有两个阶段：
  • 第一阶段：当用户希望在此阶段提交事务时，协调器向所有下属发送准备消息。当下属收到 PREPARE 消息时，要么记录 PREPARE 日志并发送 YES VOTE，如果下属愿意 COMMIT，则进入 PREPARED 状态；或者如果下属不愿意 COMMIT，它会创建一个中止记录并发送 NO VOTE。因为它知道协调器将发出中止，所以发送 NO VOTE 的下属不需要进入 PREPARED 状态。在这种情况下，NO VOTE 起到否决权的作用，因为取消交易只需要一个 NO VOTE。
  • 第二阶段：协调员做出决定后，必须将该决定传达给下属。如果选择了 COMMIT，则协调者进入提交状态并向所有下属发送 COMMIT 消息，通知他们选择。下属收到 COMMIT 消息后，进入 committing 状态，向 coordinator 发送确认（ACK）消息。当协调器收到 ACK 消息时，事务完成。另一方面，如果协调器做出 ABORT 决定，它会向所有下属发送 ABORT 消息。在这种情况下，协调器不需要向 NO VOTE 下属发送 ABORT 消息。
• 线性2PC：线性2PC中的下属，可以相互通信。这些站点从 1 到 N 编号，站点 1 是协调器。结果，PREPARE 消息以顺序方式传播。因此，与集中式或分散式方法相比，交易完成所需的时间更长。最后，节点 N 发出 Global COMMIT。
• 分布式 2 PC：分布式 2PC 的所有节点相互交互。与其他 2PC 技术不同，此过程不需要第二阶段。此外，为了知道每个节点都投了票，每个节点都必须持有所有参与节点的列表。当协调器向所有参与节点传递 PREPARE 消息时，分布式 2PC 启动。当参与者收到 PREPARE 消息时，它将他或她的投票发送给所有其他参与者。因此，每个节点都会跟踪每个交易的参与者。