基于binlog补偿机制的分布式事务服务方法及系统

摘要

本发明涉及一种基于binlog补偿机制的分布式事务服务方法，包括以下步骤：S1：将分布式事务的操作写入MySql的binlog事件中；S2：获取分布式事务的binlog事件，并对所述binlog事件进行解析，获得解析后的binlog数据；S3：根据所述解析后的binlog数据，判断所述分布式事务是否提交成功；若提交不成功，则取出与所述解析后的binlog数据对应的binlog事件，根据所述对应的binlog事件构造反向补偿的Sql语句并加以执行；否则完成。本发明还涉及一种基于binlog补偿机制的分布式事务服务系统。

说明书

技术领域

本发明涉及计算机网络技术领域，尤其涉及一种基于binlog补偿机制的分布式事务服务方法及系统。

背景技术

OLTP(On-Line Transaction Processing，联机事务处理)主要是执行基本的、日常的事务处理，比如数据库记录的增、删、改、查，对实时性要求较高。分布式事务作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行，具有原子性、一致性、隔离性、持久性。分布式事务涉及多个分布在不同地方的数据库，但对数据库的操作必须全部被提交或者回滚。只要任一数据库操作失败，所有参与事务的数据库都需要回滚。事务补偿是指对一个分布式事务做反向操作，比如一个分布式事务对一张表插入n条数据，则反向补偿时要将对应的n条数据删除。binlog(binary log，二进制日志)是MySql执行改动产生的日志文件，以二进制的形式保存在磁盘中，可用于数据恢复和主从同步。

在OLTP系统领域中，很多业务场景下都会面临事务一致性方面的需求，最典型的场景如转账业务，用户A给用户B转账，首先A账户扣款，然后B账户存入相应的金额，这两步操作要么全部成功，要么全部失败。任何一方成功、另一方失败，都会造成数据不一致。

如果上述两个步骤涉及的是同一个数据库，则只需要借助关系型数据库自带的事务管理机制即可实现事务性的需求。然而现在大型互联网平台往往是由一系列分布式系统构成的，因此一笔业务处理可能需要调用多个“服务”并操作多个数据库才能完成，因此仅仅依赖关系型数据库自带的事务机制已经满足不了我们的需求。针对这一情况，现在业界提出的解决方案一般有两阶段提交协议(Two Phase Commit Protocol，2PC协议)和事务补偿机制。

两阶段提交协议可以保证数据的强一致性，它是协调所有分布式原子事务参与者，并决定提交或者回滚的分布式算法。在两阶段提交协议中，系统一般包含两类机器(或节点)：一类为协调者，通常一个系统中只有一个，另一类为事务参与者，一般包含多个。顾名思义，两阶段提交协议由两个阶段组成，其分别为请求阶段和提交阶段。在请求阶段，协调者通知所有的事务参与者准备提交事务或者取消事务，然后进入决策过程，所有的参与者告知协调者自己的决策：同意提交事务或者取消事务。在提交阶段，协调者会根据所有参与者的决策来决定是提交事务还是取消，当且仅当所有的参与者都准备好提交事务时，事务协调者才会给所有参与者发出提交事务的通知，否则，通知所有参与者取消事务。

事务补偿机制指的是在一个分布式事务中，涉及到的所有数据库原子事务都必须存在一个对应的逆向补偿服务。分布式事务处理到中间状态失败时，对已经处理的数据库原子事务做反向补偿操作，达到访问数据库最终一致的要求，比如：第一个数据库提交成功后，访问第二个数据库失败时，需要在业务代码中，对第一个数据库提交成功的数据，做反向补偿操作。

对于两阶段提交来说，该协议有一些缺点：

同步阻塞：节点在等待消息的时候处于阻塞状态，节点中其他进程需要访问公共资源时则需要等待阻塞进程释放该资源。

单点故障：如果协调者发生了故障，那么参与者将无法完成事务而一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。

数据不一致：在提交阶段中，如果协调者在向一部分参与者发送提交通知后发生了故障，则收到通知的参与者会提交事务，而未收到通知的参与者无法执行事务提交，这会导致整个分布式系统中的数据不一致。

现有的事务补偿机制也同样存在一些问题，例如会造成代码量庞大，耦合性高。而且非常有局限性，具体是因为很多的业务无法简单的实现回滚。如果串行的服务很多，回滚的成本实在太高，开发效率低下，尤其是在复杂场景下。

发明内容

有鉴于此，本发明提供一种基于binlog补偿机制的分布式事务服务方法及系统，能够根据MySql数据库的binlog解析构造反向补偿Sql语句，来进行数据库事务反向补偿保障数据一致性，减少业务方的代码量，且耦合度低，并且分布式事务的提交和补偿都是非阻塞的。

为实现上述目的，根据本发明的一个方面，提供了一种基于binlog补偿机制的分布式事务服务方法。

本发明的基于binlog补偿机制的分布式事务服务方法包括以下步骤：S1：将分布式事务的操作写入MySql的binlog事件中；S2：获取分布式事务的binlog事件，并对所述binlog事件进行解析，获得解析后的binlog数据；S3：根据所述解析后的binlog数据，判断所述分布式事务是否提交成功；若提交不成功，则取出与所述解析后的binlog数据对应的binlog事件，根据所述对应的binlog事件构造反向补偿的Sql语句并加以执行；否则完成。

可选地，在步骤S1之前，开启所述MySql的binlog写入功能，并且将所述MySql的binlog格式设置为ROW模式。

可选地，在步骤S3之前，设置所述分布式事务的超时时间；若在步骤S3中提交不成功，则判断是否收到补偿通知；若收到补偿通知，则取出所述解析后的binlog数据对应的binlog事件，根据所述对应的binlog事件构造反向补偿的Sql语句并加以执行；若没有收到补偿通知，则判断是否到达所述超时时间；若到达所述超时时间，则取出所述解析后的binlog数据对应的binlog事件，根据所述对应的binlog事件构造反向补偿的Sql语句并加以执行；否则根据所述解析后的binlog数据，判断所述分布式事务是否提交成功。

可选地，所述ROW模式下的binlog-row-image设置为full。

可选地，步骤S1还包括：创建数据库的事务表和状态字段，所述事务表用于记录所述数据库和所述操作的相关信息。

可选地，所述相关信息包括但不局限于：唯一标识相应记录的主键id、所述数据库参与的分布式事务的id、所述分布式事务涉及的所有数据库的信息、记录所述数据库提交所述分布式事务的时间戳。

可选地，反向补偿的Sql语句执行成功之后，删除所述事务表中的所有记录，并将状态字段设置为完成；所述分布式事务提交成功之后，将状态字段设置为完成。

可选地，在步骤S2中获得解析后的binlog数据后，将解析后的binlog数据进行封装处理，并将封装的binlog数据存储在Redis或Memcache中。

可选地，以数据库参与的分布式事务的id和数据库唯一标识为key，以封装好的、一个数据库事务所涉及的所有操作为value，将封装的binlog数据存储到Redis或Memcache中。

根据本发明的另一方面，提供了一种基于binlog补偿机制的分布式事务服务系统。

本发明的基于binlog补偿机制的分布式事务服务系统包括：写入模块，用于将分布式事务的操作写入MySql的binlog事件中；解析模块，用于获取分布式事务的binlog事件，并对所述binlog事件进行解析，获得解析后的binlog数据；判断和操作模块，用于根据所述解析后的binlog数据，判断所述分布式事务是否提交成功；若提交不成功，则所述判断和操作模块还用于取出所述解析后的binlog数据对应的binlog事件，根据所述对应的binlog事件构造反向补偿的Sql语句并加以执行；否则完成。

可选地，还包括设置模块，用于开启所述MySql的binlog写入功能，并且将所述MySql的binlog格式设置为ROW模式。

可选地，所述判断和操作模块还用于设置所述分布式事务的超时时间；若在所述判断和操作模块中提交不成功，则所述判断和操作模块判断是否收到补偿通知；若收到补偿通知，则所述判断和操作模块取出所述解析后的binlog数据对应的binlog事件，根据所述对应的binlog事件构造反向补偿的Sql语句并加以执行；若没有收到补偿通知，则所述判断和操作模块判断是否到达所述超时时间；若到达所述超时时间，则所述判断和操作模块取出所述解析后的binlog数据对应的binlog事件，根据所述对应的binlog事件构造反向补偿的Sql语句并加以执行；否则判断和操作模块根据所述解析后的binlog数据，判断所述分布式事务是否提交成功。

可选地，所述设置模块还用于将所述ROW模式下的binlog-row-image设置为full。

可选地，还包括创建模块，用于创建数据库的事务表和状态字段，所述事务表用于记录所述数据库和所述操作的相关信息。

可选地，所述相关信息包括但不局限于：唯一标识相应记录的主键id、所述数据库参与的分布式事务的id、所述分布式事务涉及的所有数据库的信息、记录所述数据库提交所述分布式事务的时间戳。

可选地，所述判断和操作模块还用于删除所述事务表中的所有记录，以及将状态字段设置为完成。

可选地，所述解析模块还用于将解析后的binlog数据进行封装处理，并将封装的binlog数据存储在Redis或Memcache中。

可选地，所述解析模块还用于以数据库参与的分布式事务的id和数据库唯一标识为key，以封装好的、一个数据库事务所涉及的所有操作为value，将封装的binlog数据存储到Redis或Memcache中。

可选地，所述分布式事务涉及的数据库通过服务器与ZooKeeper连接。

根据本发明的技术方案，将分布式事务的操作写入MySql的binlog事件，并根据解析后的binlog数据判断分布式事务是否提交成功，若提交不成功，则取出与解析后的binlog数据对应的binlog事件，根据对应的binlog事件构造反向补偿的Sql语句并加以执行，进而保障了分布式事务的一致性。其中在反向补偿中，若收到补偿通知，则在收到补偿通知之后开始对相应的数据库事务做反向补偿操作。在没有收到补偿通知，可根据设置的超时时间判断是否进行补偿。补偿通知和超时时间的双重判断机制，更能有效的保障数据的一致性。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的基于binlog补偿机制的分布式事务服务方法的主要步骤的示意图；

图2是根据本发明实施例的基于binlog补偿机制的分布式事务服务方法的流程图；

图3是根据本发明实施例的基于binlog补偿机制的分布式事务服务系统的主要模块的示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的基于binlog补偿机制的分布式事务服务方法的主要步骤的示意图。

如图1所示，本发明实施例的基于binlog补偿机制的分布式事务服务方法的主要步骤包括：

S1：将分布式事务的操作写入MySql的binlog事件中。

在将分布式事务写入MySql的binlog事件之前，需要做相应的准备工作，例如：开启MySql的binlog写入功能，并且将MySql的binlog格式设置为ROW模式。在ROW模式下的binlog日志内容会非常清楚地记录下每一行数据修改的细节，方便根据日志内容构造反向补偿的Sql语句。进一步，将ROW模式下的binlog-row-image设置为full，在该模式下，binlog日志中会详细记录表中每行数据更新前后的记录。

S2：获取分布式事务的binlog事件，并对binlog事件进行解析，获得解析后的binlog数据。

在步骤S2中，会不断获取到数据库的binlog事件，对binlog事件解析之后，将解析后的binlog数据按照数据库事务为单位封装好，并以xa_id(数据库参与的分布式事务的id)和数据库唯一标识为key，以封装好的、一个数据库事务所涉及到的所有操作为value存储到Redis或Memcache中，以便之后做反向补偿所用。

S3：根据解析后的binlog数据，判断分布式事务是否提交成功；若提交不成功，则取出与解析后的binlog数据对应的binlog事件，根据对应的binlog事件构造反向补偿的Sql语句并加以执行；否则完成。

为了记录分布式事务的运行状态，以及数据库和操作的相关信息，步骤S1还包括：创建数据库的事务表(transaction表)和状态字段(status字段)，其中，事务表用于记录数据库和操作的相关信息，状态字段则用于描述事务表的记录的状态。

事务表记录的数据库和操作的相关信息包括：唯一标识相应记录的主键id、数据库参与的分布式事务的id、分布式事务涉及的所有数据库的信息、记录数据库提交分布式事务的时间戳，分别记为主键id、xa_id、db_set、timestamp。每一个数据库中都会有一张事务表，该表是判断分布式事务服务的数据库事务是否需要补偿的关键。对于在一个分布式事务中涉及到的每一个数据库，都会在该库的事务表中插入一条相同的记录，比如：一个分布式事务需要同时操作DB1、DB2和DB3，该分布式事务的ID为64e04a9fe21e，在该分布式事务中的第一个数据库事务提交的时间戳为1467343573281，则在DB1、DB2和DB3的事务表中都会插入一条同样的记录(主键id也许不同)，如下表所示：

12364e04a9fe21eDB1、DB2、DB31467343573281

上述表的作用是作为分布式事务服务在判断事务超时之后补偿事务的依据。

除了在每个数据库中建立事务表以外，还需在业务表中添加一个状态字段，用于描述该条记录的状态。虽然在一个分布式事务中，有些数据库事务已经提交，但整个分布式事务还处于一个中间状态，该状态字段即标识了这个中间状态，可以在所有数据库事务提交成功或者全部补偿完成时，更新该状态字段状态，使记录结束中间状态。

图2是根据本发明实施例的基于binlog补偿机制的分布式事务服务方法的流程图。

如图2所示，本发明实施例的基于binlog补偿机制的分布式事务服务方法的流程图为：

S10：开始一个分布式事务之后，在一个代码块中，与普通数据库事务一样，依次提交各个数据库事务。

S20：每提交一个数据库事务，都会在对应数据库的事务表中插入一条记录，记录的数据如上文所示，并将业务数据的状态设为未完成。当其他事务查询到该记录时，可自行决定如何处理该中间状态的记录，例如修改或删除该中间状态的记录。同时，在向数据库中插入、删除或更新数据之后，MySql会将相应的记录详细地记录在binlog事件以及事务表中，所记录的信息足以用来恢复到更新之前的状态。

S30：不断获取到数据库的binlog事件，并对binlog事件进行解析，获得解析后的binlog事件。对binlog事件解析之后按照数据库事务为单位封装好，并以xa_id和数据库唯一标识为key，以封装好的、一个数据库事务所涉及到的所有操作为value缓存到Redis或Memcache中，以便之后做反向补偿所用。

S40：根据解析后的binlog数据，判断分布式事务是否提交成功；若提交不成功，则进行S50，否则进行S80。

S50：判断是否收到补偿通知，若收到补偿通知，则进行S60，否则进行S9。如果在一个分布式事务中的某个数据库事务提交失败，则需要向系统发出补偿通知，该通知中会明确指出需要补偿的分布式事务的xa_id，以及需要补偿的数据库的id。

S60：在收到业务方发送的通知之后，根据xa_id和数据库唯一标识的组合作为key从Redis或Memcache中取出解析后的binlog数据对应的binlog事件，根据binlog事件构造反向补偿的Sql语句并加以执行，执行成功之后从Redis中删除该记录。

S70：将需要做补偿的数据库记录补偿完毕之后，删除对应事务表中的记录。

S80：将状态字段设置为完成。

S90：判断是否达到超时时间，若达到超时时间，则进行S60，否则进行S40。在业务方准备发出补偿通知时发生故障，则通知无法发出补偿通知，这时可以根据事务表中记录的timestamp时间戳和设置的超时时间来判断是否需要补偿。故而，在S90之前，需设置超时时间。分布式事务服务等到超时时间到达之后，根据事务表中所记录的xa_id和db_set，去Redis中查询该分布式事务所涉及的数据库事务的binlog记录是否已完全记录，若没有，则判断出该分布式事务在超时时间之内没有完全提交成功，需要对已经提交的数据库事务做反向补偿。超时补偿机制的存在使得在业务方准备发出补偿通知时出现故障也不会影响补偿的进行。

本发明公开的基于binlog补偿机制的分布式事务服务方法，在分布式事务提交时，此分布式事务所涉及的所有数据库事务不需像两阶段提交方式那样阻塞等待彼此的第一阶段提交结果，本发明中的数据库事务一次提交之后可以立即返回，事务的确认操作在后台完成。另外，如果分布式事务其中任何一个数据库事务失败，使用者的代码无须阻塞在此以等待所有的补偿操作结束之后再进行其他操作，而是可以在分布式事务提交之后就转而去处理别的逻辑，所有的补偿操作都是在后台完成，不影响使用者。故而，本发明公开的基于binlog补偿机制的分布式事务服务方法对于分布式事务的提交和事务的补偿都是非阻塞的。

本发明公开的基于binlog补偿机制的分布式事务服务方法是高可用的，分布式事务服务系统是以集群的形式存在的，在节点出现故障时可以迅速将故障节点的工作迁移到其他节点。也就是说对于分布式事务，本方法中的节点村子主节点和备份节点，主备节点通过ZooKeeper是实现高可用，一旦主节点不可用，可立即切换到备份节点继续提供服务。

图3是根据本发明实施例的基于binlog补偿机制的分布式事务服务系统的主要模块的示意图。

如图3所示，本发明实施例的基于binlog补偿机制的分布式事务服务系统3主要包括写入模块31、解析模块32以及判断和操作模块32。写入模块31用于将分布式事务的操作写入MySql的binlog事件中；解析模块32用于获取分布式事务的binlog事件，并对binlog事件进行解析，获得解析后的binlog数据；判断和操作模块33用于根据解析后的binlog数据，判断分布式事务是否提交成功；若提交不成功，则判断和操作模块还用于取出解析后的binlog数据对应的binlog事件，根据对应的binlog事件构造反向补偿的Sql语句并加以执行；否则完成。

本发明实施例的基于binlog补偿机制的分布式事务服务系统还包括设置模块，用于开启MySql的binlog写入功能，并且将MySql的binlog格式设置为ROW模式。设置模块还用于将ROW模式下的binlog-row-image设置为full。另外，判断和操作模块还用于设置所述分布式事务的超时时间。在判断和操作模块中提交不成功，则判断和操作模块判断是否收到补偿通知；若收到补偿通知，则判断和操作模块取出解析后的binlog数据对应的binlog事件，根据对应的binlog事件构造反向补偿的Sql语句并加以执行；若没有收到补偿通知，则判断和操作模块判断是否到达超时时间；若到达超时时间，则判断和操作模块取出解析后的binlog数据对应的binlog事件，根据对应的binlog事件构造反向补偿的Sql语句并加以执行；否则判断和操作模块根据解析后的binlog数据，判断分布式事务是否提交成功。

本发明实施例的基于binlog补偿机制的分布式事务服务系统还包括创建模块，用于创建数据库的事务表和状态字段，事务表用于记录数据库和操作的相关信息。其中，相关信息包括但不局限于：唯一标识相应记录的主键id、数据库参与的分布式事务的id、分布式事务涉及的所有数据库的信息、记录数据库提交分布式事务的时间戳。判断和操作模块还用于删除事务表中的所有记录，以及将状态字段设置为完成。

解析模块还用于将解析后的binlog数据进行封装处理，并将封装的binlog数据存储在Redis或Memcache中。解析模块以数据库参与的分布式事务的id和数据库唯一标识为key，以封装好的、一个数据库事务所涉及的所有操作为value，将封装的binlog数据存储到Redis或Memcache中，以便判断数据库事务是否需要补偿。

分布式事务涉及的数据库通过服务器与ZooKeeper连接，本发明实施例的基于binlog补偿机制的分布式事务服务系统是个分布式系统，当其中某个节点发生故障之后，可有其他节点迅速接管该节点的工作，即系统具有备份节点，主备节点通过ZooKeeper是实现高可用，一旦主节点不可用，可立即切换到备份节点继续提供服务。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。