CN106547610A - 一种分布式事务提交的方法及系统 - Google Patents

Abstract

本发明公开了一种分布式事务提交方法及系统，在传统的分布式事务两阶段提交的方法基础上，通过增加了准备模块，用于当部分参与者超时未收到来自协调者的命令，或收到来自协调者的乱序命令，则与其他参与者进行通信后，根据大多数原则决定执行“提交”还是“撤销”命令。解决了在事务提交阻塞发生阶段可能会出现消息等待超时、消息乱序导致数据不一致的问题，提高了分布式事务提交的效率。

Description

一种分布式事务提交的方法及系统

技术领域

本发明涉及数据库技术领域，特别是指一种分布式事务提交的方法及系统。

背景技术

数据一致性问题是分布式数据库研究的一个重点，在分布式数据库中各节点上的恢复管理保证本节点数据的一致性，事务管理则负责整个分布式事务的数据一致性，两部分协调保证整个数据库系统的数据一致性和高可用性。在事务的正常执行下，提交协议可以保证分布式事务的数据一致性，但是在发生阻塞故障的情况下，需要对提交协议作优化、改进来解决，最广泛使用的提交协议是两阶段提交协议，其过程如下：

分布式事务的某一个代理指定为协调者，所有其他代理称为参与者，只有协调者才有提交或撤销事务的决定权，其他参与者各自负责在本地数据库中执行操作，并向协调者提出撤销或提交子事务的意向。两阶段提交协议将事务提交操作分为两个阶段：

第一阶段表决阶段，分布式事务T的协调者试图提交该事务，向参与者发送“准备提交”消息，每个接收到消息的节点决定该节点上T的子事务是提交还是中止，如果节点参与者希望提交其子事务，则进入向协调者发送“准备提交”消息，进入“准备提交”的状态并等待协调者回答；如果节点希望中止其子事务，则向协调者发送“撤销”消息。

第二阶段执行阶段，从协调者收到来自各个节点的响应开始，如果协调者从所有参与者接收到的都是“提交”，那么它决定提交T，并且向所有参与者发送全局“提交”消息；如果协调者收到来自一个或多个节点的“撤销”消息，那么它向所有参与者发送消息“撤销”；其中，当某些节点因为链路断开或机器故障无法响应，协调者在超时仍未收到响应时，认为该参与者决定“撤销”。参与者收到“提交”消息，该节点提交本地的子事务，参与者收到“撤销”消息，该节点中止本地的子事务。

可见上述的分布式两阶段提交协议，无法解决在事务提交阻塞发生阶段可能会出现消息等待超时、消息乱序导致数据不一致等问题，即无法解决解决参与者超时尚未收到协调者的命令或收到乱序命令时参与者应执行何种操作，以及协调者超时未收到全部参与者响应结果时协调者应该如何操作的问题。

发明内容

有鉴于此，本发明的目的在于提出一种具有延时判决功能的分阶段分布式事务提交的方法及系统。

基于上述目的本发明提供的分布式事务提交的方法包括：

分布式事务的协调者向各个参与者发送“预提交”消息；

每个参与者接收到“预提交”消息后，决定当前节点上的子事务是否提交，若是，向所述协调者发送“准备提交”消息，否则，向协调者发送“撤销”消息；

当所述协调者接收到一个或以上的“撤销”消息，所述协调者向全部参与者发出全局“撤销”命令，如果最终所述协调者没有接收到“撤销”消息，则所述协调者发出全局“提交”的命令；

当全部参与者都收到来自所述协调者发出全局“提交”或全局“撤销”命令，则全部参与者进入“准备就绪”状态；当部分参与者超时未收到来自协调者的命令，或收到来自协调者的乱序命令，则与其他参与者进行通信后，根据大多数原则决定执行“提交”还是“撤销”命令，随后全部参与者进入“准备就绪”的状态；

判断所有参与者决定执行“提交”命令还是“撤销”命令，当所有参与者决定执行“提交”命令，每个参与者的节点提交本地子事务，当所有参与者决定执行“撤销”命令，则每个节点中止本地子事务；各参与者执行命令完毕后向所述协调者返回确认“提交”或确认“撤销”消息；

所述协调者接收参与者的返回确认消息，结束所述分布式事务。

该分布式事务提交的方法，在执行步骤：所述当所述协调者接收到一个或以上的“撤销”消息，所述协调者向全部参与者发出全局“撤销”的命令之前进一步包括：

所述协调者在没接收到全部参与者的“准备提交”或“撤销”消息之前，继续等待，直至收到来自全部参与者的响应。

进一步的，所述与其他参与者进行通信后，根据大多数原则决定执行“提交”还是“撤销”命令包括：

未收到协调者命令或收到乱序命令的参与者与其他参与者进行通信，获取其他参与者执行命令信息；

当获取的其他参与者的执行命令信息中包含有“提交”命令信息，则所述未收到协调者命令或收到乱序命令的参与者决定执行“提交”命令；

当获取的其他参与者的执行命令信息中包含有“撤销”命令信息，则所述未收到协调者命令或收到乱序命令的参与者决定执行“撤销”命令。

进一步的该方法还包括：当所述协调者发送所述“预提交”消息时，将所述“预提交”消息记录在所述协调者的日志中；

当所述协调者发送所述全局“提交”命令或全局“撤销”命令时，将所述全局“提交”命令或全局“撤销”命令消息记录在所述协调者的日志中；

当所述协调者接收参与者的返回确认消息，结束所述分布式事务时，将“结束事务”消息记录在所述协调者的日志中。

进一步的该方法还包括：当所述参与者向所述协调者发送“准备提交”或“撤销”消息时，将所述“准备提交”或“撤销”消息记录在所述参与者的日志中；

当所有参与者决定执行“提交”命令或决定执行“撤销”命令，将所述“提交”命令或“撤销”命令消息记录在所述参与者的日志中。

另一方面，本发明还提供分布式事务提交的系统，包括：

第一收发模块，用于分布式事务的协调者向各个参与者发送“预提交”消息；

第二收发模块，用于每个参与者接收到“预提交”消息后，决定当前节点上的子事务是否提交，若是，向所述协调者发送“准备提交”消息，否则，向协调者发送“撤销”消息；

第三收发模块，用于当所述协调者接收到一个或以上的“撤销”消息，所述协调者向全部参与者发出全局“撤销”命令，如果最终所述协调者没有接收到“撤销”消息，则所述协调者发出全局“提交”的命令；

准备模块，用于当全部参与者都收到来自所述协调者发出全局“提交”或全局“撤销”命令，则全部参与者进入“准备就绪”状态；当部分参与者超时未收到来自协调者的命令，或收到来自协调者的乱序命令，则与其他参与者进行通信后，根据大多数原则决定执行“提交”还是“撤销”命令，随后全部参与者进入“准备就绪”的状态；

执行模块，用于判断所有参与者决定执行“提交”命令还是“撤销”命令，当所有参与者决定执行“提交”命令，每个参与者提交本地子事务，当所有参与者决定执行“撤销”命令，则每个参与者中止本地子事务；各参与者执行命令完毕后向所述协调者返回确认“提交”或确认“撤销”消息；

第四收发模块，用于所述协调者接收参与者的返回确认消息，结束所述分布式事务。

进一步的，所述第三收发模块，进一步用于所述协调者在没接收到全部参与者的“准备提交”或“撤销”消息之前，继续等待，直至收到来自全部参与者的响应。

进一步的，所述准备模块还用于：当部分参与者超时未收到来自协调者的命令或收到来自协调者的乱序命令时；

未收到命令或收到乱序命令的参与者与其他参与者进行通信，获取其他参与者执行命令信息；

若获取的其他参与者的执行命令信息中包含有“提交”命令信息，所述未收到协调者命令或收到乱序命令的参与者决定执行“提交”命令；

若获取的其他参与者的执行命令信息中包含有“撤销”命令信息，则所述未收到协调者命令或收到乱序命令的参与者决定执行“撤销”命令。

进一步的，该系统还包括第一记录模块，用于当所述协调者发送所述“预提交”消息时，将所述“预提交”消息记录在所述协调者的日志中；

所述第一记录模块还用于当所述协调者发送所述全局“撤销”命令或全局“撤销”命令时，将所述全局“撤销”命令或全局“撤销”命令消息记录在所述协调者的日志中；

以及用于当所述协调者接收参与者的返回确认消息，结束所述分布式事务时，将“结束事务”消息记录在所述协调者的日志中。

进一步的，该系统还包括第二记录模块，用于当所述参与者向所述协调者发送“准备提交”或“撤销”消息时，将所述“准备提交”消息记录在所述参与者的日志中；

以及用于当所有参与者决定执行“提交”命令或决定执行“撤销”命令，将所述“提交”命令或“撤销”命令消息记录在所述参与者的日志中。

本发明提供的分布式事务提交的方法及系统，在执行阶段，当部分参与者超时未收到来自协调者的命令，或收到来自协调者的乱序命令时，通过其他参与者进行通信后，根据大多数原则决定执行“提交”还是“撤销”命令，随后全部参与者进入“准备就绪”的状态，解决了在事务提交阻塞发生阶段可能会出现消息等待超时、消息乱序导致数据不一致的问题，提高了分布式事务提交的效率。

附图说明

图1为本发明提供的分布式事务提交的方法的一个实施例流程图示意图；

图2为本发明提供的分布式事务提交的方法的另一个实施例流程图示意图；

图3为本发明提供的分布式事务提交的系统的一个实施例示意图；

图4为本发明提供的分布式事务提交的系统的另一个实施例示意图；

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。

需要说明的是，本发明实施例中所有使用“第一”和“第二”的表述均是为了区分两个相同名称非相同的实体或者非相同的参量，可见“第一”“第二”仅为了表述的方便，不应理解为对本发明实施例的限定，后续实施例对此不再一一说明。

本发明提供的分布式事务提交的方法的一个实施例，包括：

步骤101，分布式事务的协调者向各个参与者发送“预提交”消息；

步骤102，每个参与者接收到“预提交”消息后，决定当前节点上的子事务是否提交，若是，向所述协调者发送“准备提交”消息，否则，向协调者发送“撤销”消息；

其中，所述参与者向所述协调者发送“准备提交”消息后进入“准备提交”，一旦进入状态，节点就不能中止其上的子事务，除非协调者指示中止事务。

步骤103，当所述协调者接收到一个或以上的“撤销”消息，所述协调者向全部参与者发出全局“撤销”命令，如果最终所述协调者没有接收到“撤销”消息，则所述协调者发出全局“提交”的命令；

步骤104，当全部参与者都收到来自所述协调者发出全局“提交”或全局“撤销”命令，则全部参与者进入“准备就绪”状态；当部分参与者超时未收到来自协调者的命令，或收到来自协调者的乱序命令，则与其他参与者进行通信后，决定执行“提交”还是“撤销”命令，随后全部参与者进入“准备就绪”的状态；

步骤105，判断所有参与者决定执行“提交”命令还是“撤销”命令，当所有参与者决定执行“提交”命令，每个参与者的节点提交本地子事务，当所有参与者决定执行“撤销”命令，则每个节点中止本地子事务；各参与者执行命令完毕后向所述协调者返回确认“提交”或确认“撤销”消息；

步骤106，所述协调者接收参与者的返回确认消息，结束所述分布式事务。

本发明提供的分布式事务提交的方法，具有延时判决的功能，通过在某些参与者在向协调者发送消息后超时尚未收到协调者的全局“提交”或者“撤销”命令或收到乱序命令时，这些参与者彼此通信，根据大多数原则决定是执行“提交”还是“撤销”命令，解决了在事务提交阻塞发生阶段可能会出现消息等待超时、消息乱序导致数据不一致的问题，提高了分布式事务提交的效率。

进一步的，步骤102，每个参与者接收到“预提交”消息后，决定当前节点上的子事务是否提交，进一步包括：当某些参与者超时未收到协调者发送的消息或收到乱序消息时，参与者间进行互相通信，根据大多数原则决定提交还是撤销；例如当某个未收到协调者信息的参与者与其他参与者进行通信，结果收到其他参与者的信息结果为20个撤销50个提交的信息，那么该参与者根据大多数原则决定提交当前子事务。

执行步骤103中的，所述当所述协调者接收到一个或以上的“撤销”消息，所述协调者向全部参与者发出全局“撤销”的命令之前进一步包括：步骤103a，所述协调者在没接收到全部参与者的“准备提交”或“撤销”消息之前，继续等待，直至收到来自全部参与者的响应。

本发明提供的分布式事务提交的方法给出协调者超时未收到全部参与者执行结果时，协调者需要执行的操作，以及所述参与者超时尚未收到命令或收到乱序命令时需要执行的操作。

进一步的，步骤104中，所述与其他参与者进行通信后，根据大多数原则决定执行“提交”还是“撤销”命令包括：

104a，未收到协调者命令的参与者与其他参与者进行通信，获取其他参与者执行命令信息；

104b，当获取的其他参与者的执行命令信息中包含有“提交”命令信息，说明协调者发送的是全局“提交”命令，即收到协调者命令的参与者均决定执行“提交”命令，则所述未收到协调者命令或收到乱序命令的参与者也决定执行“提交”命令；

104c，当获取的其他参与者的执行命令信息中包含有“撤销”命令信息，同理，所述未收到协调者命令或收到乱序命令的参与者执行“撤销”命令。

进一步的，在步骤101中，当所述协调者发送所述“预提交”消息时，执将所述“预提交”消息记录在所述协调者的日志中；

在步骤103中，当所述协调者发送所述全局“提交”命令或全局“撤销”命令时，将所述全局“提交”命令或全局“撤销”命令消息记录在所述协调者的日志中；

在步骤106中，当所述协调者接收参与者的返回确认消息，结束所述分布式事务时，将“结束事务”消息记录在所述协调者的日志中。

进一步的，在步骤102中，当所述参与者向所述协调者发送“准备提交”或“撤销”消息时，将所述“准备提交”或“撤销”消息记录在所述参与者的日志中；

以及在步骤105中当所有参与者决定执行“提交”命令或决定执行“撤销”命令，将所述“提交”命令或“撤销”命令消息记录在所述参与者的日志中。

本发明提供的分布式事务提交方法进一步将所述协调者和所属参与者将发送的命令或反馈信息记录各自的日志中，便于需要时进行错误排查。

本发明提供的分布式事务提交的方法的另一个实施例，包括：

步骤201a，分布式事务的协调者试图提交该事务；步骤201b，分布式事务的协调者向各个参与者发送“预提交”消息，并将所述“预提交”消息记录在所述协调者的日志中。

步骤202a，每个参与者接收到“预提交”消息；步骤202b，每个参与者决定当前节点上的子事务是否提交，其中当某些参与者超时未收到协调者的消息或收到乱序消息，参与者之间互相通信，根据；步骤202b，若决定提交事务，向所述协调者发送“准备提交”消息，同时将所述“准备提交”消息记录在所述参与者的日志中；步骤202b，若决定撤销事务，向协调者发送“撤销”消息，同时将所述“撤销”消息记录在所述参与者的日志中。

步骤203a，所述协调者等待接收参与者的反馈信息；步骤203b，判断是否收到撤销消息；步骤203c，当所述协调者接收到一个或以上的“撤销”消息，所述协调者向全部参与者发出全局“撤销”命令，并将所述全局“撤销”消息记录在所述协调者的日志中；所述协调者在没接收到全部参与者的反馈消息之前，返回执行步骤203c继续等待，直至收到来自全部参与者的响应；步骤203d，如果最终所述协调者没有接收到“撤销”消息，则所述协调者发出全局“提交”的命令，并将所述全局“提交”消息记录在所述协调者的日志中。

步骤204a，全部参与者等待接收协调者的命令；步骤204b，当全部参与者都收到来自所述协调者发出全局“提交”或全局“撤销”命令，则全部参与者进入“准备就绪”状态；步骤204c，当部分参与者超时未收到来自协调者的命令，或收到来自协调者的乱序命令，则与其他参与者进行通信后，根据其他参与者执行命令信息包含“提交”还是“撤销”信息，相应的决定执行“提交”还是“撤销”命令，随后全部参与者进入步骤204b“准备就绪”的状态。

步骤205a，判断所有参与者决定执行“提交”命令还是“撤销”命令；步骤205b，当所有参与者决定执行“提交”命令，将所述“提交”命令消息记录在所述参与者的日志中；步骤205c，然后每个参与者的节点提交本地子事务并向所述协调者返回确认“提交”消息；步骤205d，当所有参与者决定执行“撤销”命令，将所述“撤销”命令消息记录在所述参与者的日志中，步骤205e，然后每个参与者中止本地子事务，各参与者同时向所述协调者返回确认“撤销”消息。

步骤206a，所述协调者接收参与者的返回确认消息，结束所述分布式事务；步骤206a，将“结束事务”消息记录在所述协调者的日志中。

可见本发明提供的分布式事务的提交方法克服了传统的两阶段提交协议在事务提交阻塞发生时存在的问题：在参与者超时尚未收到协调者的命令或收到参与者收到乱序命令时，参与者执行彼此通信并给出决策；协调者超时未收到全部参与者执行结果时，协调者继续等待，直到收到全部反馈；通过给出参与者超时尚未收到协调者的命令者或收到乱序信息时，参与者需要执行的操作，给出协调者超时未收到全部参与者执行结果时，协调者需要执行的操作，解决了在事务提交阻塞发生阶段可能会出现消息等待超时、消息乱序导致数据不一致的问题，提高了分布式事务提交的效率。

另一方面，本发明提供的分布式事务提交的系统的一个实施例，包括：

第一收发模块1，用于分布式事务的协调者向各个参与者发送“预提交”消息；

第二收发模块2，用于每个参与者接收到“预提交”消息后，决定当前节点上的子事务是否提交，若是，向所述协调者发送“准备提交”消息，否则，向协调者发送“撤销”消息；

第三收发模块3，用于当所述协调者接收到一个或以上的“撤销”消息，所述协调者向全部参与者发出全局“撤销”命令，如果最终所述协调者没有接收到“撤销”消息，则所述协调者发出全局“提交”的命令；

准备模块4，用于当全部参与者都收到来自所述协调者发出全局“提交”或全局“撤销”命令，则全部参与者进入“准备就绪”状态；当部分参与者超时未收到来自协调者的命令，或收到来自协调者的乱序命令，则与其他参与者进行通信后，决定执行“提交”还是“撤销”命令，随后全部参与者进入“准备就绪”的状态；

执行模块5，用于判断所有参与者决定执行“提交”命令还是“撤销”命令，当所有参与者决定执行“提交”命令，每个参与者提交本地子事务，当所有参与者决定执行“撤销”命令，则每个参与者中止本地子事务；各参与者执行命令完毕后向所述协调者返回确认“提交”或确认“撤销”消息；

第四收发模块6，用于所述协调者接收参与者的返回确认消息，结束所述分布式事务。

本发明提供的分布式事务提交系统，具有延时判决的功能，通过增加准备模块4，在某些参与者在向协调者发送消息后超时尚未收到协调者的全局“提交”或者“撤销”命令或收到乱序命令时，这些参与者彼此通信，根据大多数原则决定是执行“提交”还是“撤销”命令，解决了在事务提交阻塞发生阶段可能会出现消息等待超时、消息乱序导致数据不一致的问题，提高了分布式事务提交的效率。

进一步的，所述第三收发模块，还用于所述协调者在没接收到全部参与者的“准备提交”或“撤销”消息之前，继续等待，直至收到来自全部参与者的响应。

进一步的，所述准备模块，还用于当部分参与者超时未收到来自协调者的命令，或收到乱序命令时，未收到协调者命令的参与者与其他参与者进行通信，获取其他参与者执行命令信息；

若获取的其他参与者的执行命令信息中包含有“提交”命令信息，所述未收到协调者命令的参与者决定执行“提交”命令；

若获取的其他参与者的执行命令信息中包含有“撤销”命令信息，所述未收到协调者命令的参与者决定执行“撤销”命令。

进一步的，该分布式事务提交系统，还包括第一记录模块307，用于第一收发模块301执行协调者发送所述“预提交”消息时，将所述“预提交”消息记录在所述协调者的日志中；

第一记录模块307还用于当第三收发模块303执行所述协调者发送所述全局“撤销”命令或全局“撤销”命令时，将所述全局“撤销”命令或全局“撤销”命令消息记录在所述协调者的日志中；

以及用于当第四收发模块306执行所述协调者接收参与者的返回确认消息，结束所述分布式事务时，将“结束事务”消息记录在所述协调者的日志中。

进一步的，该分布式事务提交系统还包括第二记录模块308，用于当第二收发模块302执行所述参与者向所述协调者发送“准备提交”或“撤销”消息时，将所述“准备提交”消息记录在所述参与者的日志中；

以及用于当执行模块305在参与者决定执行“提交”命令或决定执行“撤销”命令时，将所述“提交”命令或“撤销”命令消息记录在所述参与者的日志中。

本发明提供的分布式事务的提交的方法及系统，克服了传统的两阶段提交协议在事务提交阻塞发生时存在的问题：在参与者超时尚未收到协调者的命令或收到参与者收到乱序命令时，参与者执行彼此通信并给出决策；协调者超时未收到全部参与者执行结果时，协调者继续等待，直到收到全部反馈；通过增加准备模块304，给出参与者超时尚未收到协调者的命令者或收到乱序信息时，参与者需要执行的操作，给出协调者超时未收到全部参与者执行结果时，协调者需要执行的操作，解决了在事务提交阻塞发生阶段可能会出现消息等待超时、消息乱序导致数据不一致的问题，提高了分布式事务提交的效率。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本发明的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本发明的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本发明难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本发明难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本发明的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本发明的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本发明。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本发明的具体实施例对本发明进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本发明的实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本发明的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种分布式事务提交的方法，其特征在于，包括：

分布式事务的协调者向各个参与者发送“预提交”消息；

每个参与者接收到“预提交”消息后，决定当前节点上的子事务是否提交，若是，向所述协调者发送“准备提交”消息，否则，向协调者发送“撤销”消息；

当所述协调者接收到一个或以上的“撤销”消息，所述协调者向全部参与者发出全局“撤销”命令，如果最终所述协调者没有接收到“撤销”消息，则所述协调者发出全局“提交”的命令；

当全部参与者都收到来自所述协调者发出全局“提交”或全局“撤销”命令，则全部参与者进入“准备就绪”状态；当部分参与者超时未收到来自协调者的命令，或收到来自协调者的乱序命令，则与其他参与者进行通信后，根据大多数原则决定执行“提交”还是“撤销”命令，随后全部参与者进入“准备就绪”的状态；

判断所有参与者决定执行“提交”命令还是“撤销”命令，当所有参与者决定执行“提交”命令，每个参与者的节点提交本地子事务，当所有参与者决定执行“撤销”命令，则每个节点中止本地子事务；各参与者执行命令完毕后向所述协调者返回确认“提交”或确认“撤销”消息；

所述协调者接收参与者的返回确认消息，结束所述分布式事务。

2.根据权利要求1所述的分布式事务提交的方法，其特征在于，执行步骤：所述当所述协调者接收到一个或以上的“撤销”消息，所述协调者向全部参与者发出全局“撤销”的命令之前进一步包括：所述协调者在没接收到全部参与者的“准备提交”或“撤销”消息之前，继续等待，直至收到来自全部参与者的响应。

3.根据权利要求1所述的分布式事务提交的方法，其特征在于，所述与其他参与者进行通信后，根据大多数原则决定执行“提交”还是“撤销”命令包括：

未收到协调者命令或收到乱序命令的参与者与其他参与者进行通信，获取其他参与者执行命令信息；

若获取的其他参与者的执行命令信息中包含有“提交”命令信息，则所述未收到协调者命令或收到乱序命令的参与者决定执行“提交”命令；

若获取的其他参与者的执行命令信息中包含有“撤销”命令信息，则所述未收到协调者命令或收到乱序命令的参与者决定执行“撤销”命令。

4.根据权利要求1所述的分布式事务提交的方法，其特征在于，当所述协调者发送所述“预提交”消息时，将所述“预提交”消息记录在所述协调者的日志中；

当所述协调者发送所述全局“提交”命令或全局“撤销”命令时，将所述全局“提交”命令或全局“撤销”命令消息记录在所述协调者的日志中；

当所述协调者接收参与者的返回确认消息，结束所述分布式事务时，将“结束事务”消息记录在所述协调者的日志中。

5.根据权利要求4所述的分布式事务提交的方法，其特征在于，当所述参与者向所述协调者发送“准备提交”或“撤销”消息时，将所述“准备提交”或“撤销”消息记录在所述参与者的日志中；

当所有参与者决定执行“提交”命令或决定执行“撤销”命令，将所述“提交”命令或“撤销”命令消息记录在所述参与者的日志中。

6.一种分布式事务提交的系统，其特征在于，包括：

第一收发模块，用于分布式事务的协调者向各个参与者发送“预提交”消息；

第二收发模块，用于每个参与者接收到“预提交”消息后，决定当前节点上的子事务是否提交，若是，向所述协调者发送“准备提交”消息，否则，向协调者发送“撤销”消息；

第三收发模块，用于当所述协调者接收到一个或以上的“撤销”消息，所述协调者向全部参与者发出全局“撤销”命令，如果最终所述协调者没有接收到“撤销”消息，则所述协调者发出全局“提交”的命令；

准备模块，用于当全部参与者都收到来自所述协调者发出全局“提交”或全局“撤销”命令，则全部参与者进入“准备就绪”状态；当部分参与者超时未收到来自协调者的命令，或收到来自协调者的乱序命令，则与其他参与者进行通信后，根据大多数原则决定执行“提交”还是“撤销”命令，随后全部参与者进入“准备就绪”的状态；

执行模块，用于判断所有参与者决定执行“提交”命令还是“撤销”命令，当所有参与者决定执行“提交”命令，每个参与者提交本地子事务，当所有参与者决定执行“撤销”命令，则每个参与者中止本地子事务；各参与者执行命令完毕后向所述协调者返回确认“提交”或确认“撤销”消息；

第四收发模块，用于所述协调者接收参与者的返回确认消息，结束所述分布式事务。

7.根据权利要求1所述的分布式事务提交的系统，其特征在于，所述第三收发模块，进一步用于所述协调者在没接收到全部参与者的“准备提交”或“撤销”消息之前，继续等待，直至收到来自全部参与者的响应。

8.根据权利要求1所述的分布式事务提交的系统，其特征在于，所述准备模块还用于：

当部分参与者超时未收到来自协调者的命令，或收到来自协调者的乱序命令，未收到命令或收到乱序命令的参与者与其他参与者进行通信，获取其他参与者执行命令信息；

若获取的其他参与者的执行命令信息中包含有“提交”命令信息，则所述未收到协调者命令或收到乱序命令的参与者决定执行“提交”命令；

若获取的其他参与者的执行命令信息中包含有“撤销”命令信息，则所述未收到协调者命令或收到乱序命令的参与者决定执行“撤销”命令。

9.根据权利要求1所述的分布式事务提交的系统，其特征在于，还包括第一记录模块，用于当所述协调者发送所述“预提交”消息时，将所述“预提交”消息记录在所述协调者的日志中；

所述第一记录模块还用于当所述协调者发送所述全局“撤销”命令或全局“撤销”命令时，将所述全局“撤销”命令或全局“撤销”命令消息记录在所述协调者的日志中；

以及用于当所述协调者接收参与者的返回确认消息，结束所述分布式事务时，将“结束事务”消息记录在所述协调者的日志中。

10.根据权利要求9所述的分布式事务提交的系统，其特征在于，还包括第二记录模块，用于当所述参与者向所述协调者发送“准备提交”或“撤销”消息时，将所述“准备提交”消息记录在所述参与者的日志中；

以及用于当所有参与者决定执行“提交”命令或决定执行“撤销”命令，将所述“提交”命令或“撤销”命令消息记录在所述参与者的日志中。