一种基于事务消息及反查实现分布式事务的方法及系统与流程

1.本发明涉及计算机技术领域，特别是一种基于事务消息及反查实现分布式事务的方法及系统。


背景技术：

2.本方法是在订单系统中实施，在该系统中创建订单的过程中实际上执行了2个步骤的操作(如下图1)：
3.(1)在订单库中插入一条订单数据，创建订单；
4.(2)发消息给消息队列，消息的内容就是刚刚创建的订单。
5.购物车系统订阅相应的主题，接收订单创建的消息，然后清理购物车，在购物车中删除订单中的商品。问题的关键点集中在订单系统，创建订单和发送消息这两个步骤要么都操作成功，要么都操作失败，不允许一个成功而另一个失败的情况出现。即有要有一个方案能够保证分布式事务的可靠性，常用的技术方案是分布式锁的机制，一定程度上面可以保障操作的原子性和一致性，但是牺牲了效率(性能)，尤其在高并发的场景下，容易出现死锁等情况。


技术实现要素：

6.为克服上述问题，本发明的目的是提供一种能够利用事务消息保证分布性事务性，并通过增加事务反查机制来解决事务消息提交失败问题的方法。
7.本发明采用以下方案实现：一种基于事务消息及反查实现分布式事务的方法，所述方法包括以下步骤：
8.步骤s1、消息发送方给消息服务端发送一个半消息；
9.步骤s2、半消息发送成功后，告知消息服务端的订单系统，订单系统开始执行半消息的本地事务；
10.步骤s3、根据本地事务的执行结果决定将半消息提交或回滚事务消息；
11.步骤s4、在半消息提交或回滚事务消息时发生网络异常，消息服务端没有收到提交半消息或回滚的请求，消息服务端会定期反查消息发送方对应的本地事务状态，根据反查结果决定提交或回滚本地事务。
12.进一步的，所述步骤s1进一步具体为：消息发送方给消息服务端发送一个半消息，所述半消息为消息的完整内容，且对于消费者不可见。
13.进一步的，所述步骤s2进一步具体为：半消息发送成功后，告知消息服务端的订单系统，订单系统开始执行本地事务，所述本地事务为业务性质的操作，如在订单库中创建一条订单记录，并提交订单库的数据库事务，所述数据库事务为连贯性的操作，业务发起，数据库执行。
14.进一步的，所述步骤s3进一步具体为：根据本地事务的执行结果决定将半消息提交或回滚事务消息，判断订单是否创建成功，是，则将事务消息提交至消息服务端，否，则回
滚事务消息。
15.进一步的，所述步骤s4进一步具体为：反查本地事务并不依赖消息发送方，消息服务端通过其他订单服务的节点数据来执行反查，确保本地事务的完整性。
16.本发明还提供了一种基于事务消息及反查实现分布式事务的系统，包括发送模块、告知模块、决定模块和反查模块，所述发送模块，即消息发送方给消息服务端发送一个半消息；所述告知模块，即半消息发送成功后，告知消息服务端的订单系统，订单系统开始执行半消息的本地事务；所述决定模块，即根据本地事务的执行结果决定将半消息提交或回滚事务消息；所述反查模块，即在半消息提交或回滚事务消息时发生网络异常，消息服务端没有收到提交半消息或回滚的请求，消息服务端会定期反查消息发送方对应的本地事务状态，根据反查结果决定提交或回滚本地事务。
17.进一步的，所述发送模块进一步具体为：消息发送方给消息服务端发送一个半消息，所述半消息为消息的完整内容，且对于消费者不可见。
18.进一步的，所述告知模块进一步具体为：半消息发送成功后，告知消息服务端的订单系统，订单系统开始执行本地事务，所述本地事务为业务性质的操作，如在订单库中创建一条订单记录，并提交订单库的数据库事务，所述数据库事务为连贯性的操作，业务发起，数据库执行。
19.进一步的，所述决定模块进一步具体为：根据本地事务的执行结果决定将半消息提交或回滚事务消息，判断订单是否创建成功，是，则将事务消息提交至消息服务端，否，则回滚事务消息。
20.进一步的，所述反查模块进一步具体为：反查本地事务并不依赖消息发送方，消息服务端通过其他订单服务的节点数据来执行反查，确保本地事务的完整性。
21.本发明的有益效果在于：本发明实现订单系统中分布式操作事务的一致性要求，同时通过事务反查的机制解决了事务消息提交失败的问题，即使是发送事务消息的那个订单服务节点宕机了，消息队列依然可以通过其他订单服务的节点来执行反查，确保事务的完整性；同时具备更好的性能指标。
附图说明
22.图1为现有技术流程示意图。
23.图2是本发明的方法流程示意图。
24.图3是本发明的系统原理框图。
具体实施方式
25.下面结合附图对本发明做进一步说明。
26.请参阅图2所示，本发明的一种基于事务消息及反查实现分布式事务的方法，所述方法包括以下步骤：
27.步骤s1、消息发送方给消息服务端发送一个半消息；
28.步骤s2、半消息发送成功后，告知消息服务端的订单系统，订单系统开始执行半消息的本地事务；
29.步骤s3、根据本地事务的执行结果决定将半消息提交或回滚事务消息；
30.步骤s4、在半消息提交或回滚事务消息时发生网络异常，消息服务端没有收到提交半消息或回滚的请求，消息服务端会定期反查消息发送方对应的本地事务状态，根据反查结果决定提交或回滚本地事务。
31.下面通过一具体实施例对本发明作进一步说明：
32.步骤1：消息发送方如订单系统消息模块客户端给消息服务端发送一个半消息(half)，这个半消息包含的内容是完整的消息内容，和普通消息的唯一区别是，在事务提交之前，对于消费者来说，这个消息是不可见的。订单系统消息模块客户端由客户端和服务端构成，一般会引入消息中间件，如rocketmq等进行构建；订单系统生成的消息推送给消息模块，消息模块会实时告知接受结果。
33.步骤2：半消息发送成功后，告知订单系统，该系统开始执行本地事务，如在订单库中创建一条订单记录，并提交订单库的数据库事务。这边的本地事务就是特指业务性质的操作，如发起订单付款操作，跟下面提到的数据库事务是连贯性的操作，业务发起，数据库执行。如发起付款，就会触发“在订单库中创建一条订单记录”；因此本案例中数据库事务完成后会反馈本地事务结果，本地事务以数据库事务结果来给用户做反馈，如提示订单创建失败等。
34.数据库事务(transaction)是访问并可能操作各种数据项的一个数据库操作序列，这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。事务由事务开始与事务结束之间执行的全部数据库操作组成。比如本发明提到的“在订单库中创建一条订单记录”，这个简单的操作在订单系统中可能涉及账户余额的预扣款、日志的更新等一系列的数据库操作，那么必须保障全部的数据库操作序列都成功或都不成功，需要放在一个事务中执行。
35.步骤3：根据本地事务的执行结果决定提交或者回滚事务消息。如果订单创建成功，那就提交事务消息至消息服务端。如果订单创建失败，那就回滚事务消息，这样就基本实现了要么都成功，要么都失败的一致性要求。回滚事务消息，是指如果步骤2创建订单数据库保存没有成功的情况下，通知消息服务端操作失败，不需要向消息订阅方(如果购物车系统)发送消息，直接删除本条消息即可。
36.步骤4：如果在提交或者回滚事务消息时发生网络异常，消息服务端没有收到提交或者回滚的请求，消息服务端会定期去消息发送方(订单系统消息模块)上反查这个事务对应的本地事务的状态，然后根据反查结果决定提交或者回滚这个事务。
37.这个反查本地事务的实现，并不依赖消息的发送方，也就是订单服务的某个实例节点上的任何数据。这种情况下，即使是发送事务消息的那个订单服务节点宕机了，消息队列依然可以通过其他订单服务的节点来执行反查，确保事务的完整性。
38.事务反查机制的实现需要业务代码中实现一个反查本地事务状态的接口，告知消息队列本地事务是成功还是失败。比如在本发明提到的订单系统中，反查本地事务的逻辑只要根据消息中的订单id，在订单库中查询这个订单是否存在即可，如果订单存在则返回成功，否则返回失败。消息队列会自动根据事务反查的结果，提交或者回滚事务消息。
39.另外这个反查本地事务的实现，并不依赖消息的发送方，也就是订单服务的某个实例节点上的任何数据。这种情况下，即使是发送事务消息的那个订单服务节点宕机了，消息队列依然可以通过其他订单服务的节点来执行反查，确保事务的完整性。
40.总之，本发明适用的场景主要是那些需要异步更新数据，并且对数据实时性要求不太高的场景，比如在背景中提到的订单系统这个实施案例，在创建订单后，如果出现短暂的1
‑
2秒，购物车里的商品没有及时删除，一定程度上也是允许的设计，只要最终购物车的数据和订单数据保持一致就可以。其总体思路是通过消息队列中的事务，解决消息生产者和消息消费者的数据一致性问题；利用事务消息保证分布式事务性；并通过增加事务反查机制来解决事务消息提交失败的问题，即使是发送事务消息的订单服务节点宕机了，消息服务依然可以通过其他订单服务的节点来执行反查，确保事务的完整性。
41.请参阅图3所示，本发明还提供了一种基于事务消息及反查实现分布式事务的系统，包括发送模块、告知模块、决定模块和反查模块，所述发送模块，即消息发送方给消息服务端发送一个半消息；所述告知模块，即半消息发送成功后，告知消息服务端的订单系统，订单系统开始执行半消息的本地事务；所述决定模块，即根据本地事务的执行结果决定将半消息提交或回滚事务消息；所述反查模块，即在半消息提交或回滚事务消息时发生网络异常，消息服务端没有收到提交半消息或回滚的请求，消息服务端会定期反查消息发送方对应的本地事务状态，根据反查结果决定提交或回滚本地事务。
42.所述发送模块进一步具体为：消息发送方给消息服务端发送一个半消息，所述半消息为消息的完整内容，且对于消费者不可见。
43.所述告知模块进一步具体为：半消息发送成功后，告知消息服务端的订单系统，订单系统开始执行本地事务，所述本地事务为业务性质的操作，如在订单库中创建一条订单记录，并提交订单库的数据库事务，所述数据库事务为连贯性的操作，业务发起，数据库执行。
44.所述决定模块进一步具体为：根据本地事务的执行结果决定将半消息提交或回滚事务消息，判断订单是否创建成功，是，则将事务消息提交至消息服务端，否，则回滚事务消息。
45.所述反查模块进一步具体为：反查本地事务并不依赖消息发送方，消息服务端通过其他订单服务的节点数据来执行反查，确保本地事务的完整性。
46.以上所述仅为本发明的较佳实施例，凡依本发明申请专利范围所做的均等变化与修饰，皆应属本发明的涵盖范围。