两阶段提交协议（分布式事务管理）

考虑给我们提供了一套杂货店，其中所有商店的负责人都想查询所有商店中可用的消毒剂库存，以便在各个商店之间移动库存，以平衡所有商店中消毒剂库存的数量。该任务由单个事务T执行，该事务T是第n^个商店中的组件T _n ，并且商店S ₀对应于管理者所在的T _0。 T执行的以下活动顺序如下：

a)交易(T)的组成部分T ₀在总部(总部)创建。

b)T ₀向所有存储发送消息，以命令它们创建组件T _i 。

c)每个T _i在商店“ i”处执行查询以发现可用消毒剂库存的数量，并将此数量报告给T _o 。

d)每个商店都收到指令并更新库存水平，并在需要时将其运送到其他商店。

但是在执行此过程期间，我们可能会遇到一些问题：

1)可能违反原子性属性，因为可能会两次指示任何商店(S _n )发送可能使数据库处于不一致状态的清单。为了确保原子性，事务T必须要么在所有站点上提交，要么必须在所有站点上中止。

2)但是，由于任何网络问题和任何其他原因，存储区T _n中的系统可能会崩溃，并且T _n永远不会收到来自T _{0的指令。}因此，问题就产生了，无论中止还是提交，运行的分布式事务都会发生什么?是否恢复?

两阶段提交协议：此协议的设计旨在解决上述问题，请考虑我们有多个分布式数据库，这些数据库是从不同的服务器(站点)运行的，假设S ₁ ，S ₂ ，S ₃ ，…. S _n 。其中每个S _i维护着所有相应活动的单独日志记录，并且转换T也已分为子交易T ₁ ，T ₂ ，T ₃ ，…， T _n ，每个T _i都分配给S _i 。所有这些由每个S _i处的单独事务管理器维护。我们分配了任何站点作为协调员。

有关此协议的一些要点：

a)在两阶段提交中，我们假设每个站点都在该站点上记录操作，但是没有全局日志。

b)协调器(C _i )在确认分布式事务是否将中止或提交时起着至关重要的作用。

c)在此协议中，使消息在协调器(C _i )与其他站点之间发送。发送每条消息时，会在每个发送站点上记录其日志，以在必要时帮助恢复。

该协议的两个阶段如下：

第一阶段–

a)首先，协调器(C _i )将日志记录放置在其站点的日志记录中。

b)然后，协调器(C _i )向所有执行transaction(T)的站点发送Prepare T消息。

c)每个站点上的事务管理器在收到此消息前， Prepare T决定是提交还是中止其T的部分(部分)。如果该组件尚未完成其活动，则该站点可能会延迟，但最终必须发送响应。

d)如果站点不想提交，则它必须写在日志记录上，并且本地事务管理器向C _i发送消息中止T。

e)如果站点想要提交，则必须在日志记录上写，并且本地事务管理器向C _i发送一条准备好的消息T。一旦发送了C _i处的就绪T消息，除了Coordinator(C _i ) ，其他任何事务都无法阻止它提交事务T的一部分。

第一阶段的消息传递

第二阶段–

第二阶段从协调器(C _i )从协作执行事务T的所有站点接收到响应中止T或提交T开始。它可能已关闭，或者已被网络断开连接。在这种情况下，将在指定适当的超时时间后，在该时间之后将其视为已发送中止T的站点。交易的命运取决于以下几点：

a)如果协调员从T的所有参与站点接收到准备好的T，则它决定提交T。然后，协调器在其站点日志记录中写入消息，并将消息commit T发送到T中涉及的所有站点。

b)如果站点收到提交T消息，它将在该站点上提交T的组件，并将其写入日志记录中。

c)如果站点收到消息中止T ，它将中止T并写入日志记录<中止T>。

d)但是，如果协调器已从一个或多个站点接收到中止T ，它将在其站点上记录<中止T> ，然后将中止T消息发送到事务T中涉及的所有站点。

第二阶段的消息传递

缺点：

a)当协调器站点故障可能导致阻塞时，将面临两阶段提交协议的主要缺点，因此必须推迟提交(或终止)Transaction(T)的决定，直到协调器恢复为止。

b)阻塞问题：考虑一个场景，如果一个Transaction(T)在活动站点的数据项上保持锁定，但是在执行过程中，如果协调器失败并且活动站点除了之外不保留任何其他日志记录或。因此，不可能确定已做出什么决定(是否要 / )。因此，在那种情况下，最终决定将延迟到协调器恢复或修复为止。在某些情况下，这可能需要一天或很长时间才能恢复，并且在此时间段内，锁定的数据项对于其他事务(T _i )仍然不可访问。此问题称为阻塞问题。