一种基于发布订阅队列的异步转同步缩短响应时间的方案的制作方法

1.本发明涉及互联网分布式服务通信技术领域，特别涉及一种基于发布订阅队列的异步转同步缩短响应时间的方案。


背景技术：

2.一般在链路较长的订单系统中，每一笔订单都涉及到状态变更，其中特别重要的是用户订单支付后，商家需要尽快获取支付结果是支付成功还是支付失败。获取结果需要的时间越长，对于用户和商家需要等待的时间越长，客户体验也会越来越差。所以本发明设计了一种异步转同步的方案，解决链路长，业务校验非常多的订单系统在传统方案下响应时间长的问题
3.图1是本方案与传统方案的优缺点的对比，解决了异步方式获取支付状态响应时间长的问题，且附带提升了通信宽带的使用效率，本方案使用的评价指标：
4.1、响应时间rt(response-time)；
5.2、往返时间rtt(round-trip time)；
6.传统的方式中，因为下单支付后只是返回中间状态，表示已收到支付请求，支付操作还在处理中。还需要商家系统反复来查询订单状态，查询的过程会消耗时间，所以响应时间比较长。


技术实现要素：

7.本发明要解决的技术问题是克服现有技术的缺陷，提供一种基于发布订阅队列的异步转同步缩短响应时间的方案，解决传统方式响应时间长的问题，使得响应在尽可能短的时间内到达商家系统，其原理是利用发布订阅队列的发布订阅机制，系统处理请求的进程订阅处理结果并等待，由消息中间件反馈结果并发布处理结果，进而使得进程获取处理结果同步返回。用此种方式替代原来异步查询处理结果的方式。
8.本发明提供了如下的技术方案：
9.本发明提供一种基于发布订阅队列的异步转同步缩短响应时间的方案，包括以下方案：
10.(1)系统同步获取中间结果后进入阻塞，等待异步最终结果通知：
11.当分布式系统(以下简称“系统”)的某个节点接收到请求时，系统组织资源开启进程a，进程a将请求转发给底层系统处理，为了用户体验，系统进程a立即返回已受理状态，注意，此时请求的处理并没有到达终态，用户仍需要等待系统处理；
12.(2)采用独立部署的发布订阅队列实现分布式多节点消息通知：
13.用户系统收到已受理状态后，不断来查询处理的最终结果，可能需要查询一到两次，甚至更多，所以表现为响应时间长。那么将系统进程a的响应改为同步响应，即系统获取已受理状态后，向独立部署的发布订阅队列订阅消息，同时进程a开始同步等待；
14.(3)利用消息中间件快速高可用的特点，发送最终结果，并触发发布订阅队列的通
知：
15.系统的所有节点事先开启了进程b用来专门接收消息中间件的最终处理结果的消息，也就是说任意一个节点都可以接受消息中间件消息，然后向发布订阅队列发布消息，那么会使得上述第(2)点中的节点中处于等待状态的进程a被激活，获取到最终的处理结果，进程a直接同步响应出去，用户同步获取最终结果。最终只需要一次请求，就能获取最终结果，缩短了响应时间(rt)。
16.与现有技术相比，本发明的有益效果如下：
17.1、基于消息中间件与发布订阅队列的结合互操作，实现异步转同步的方式替代异步返回同步查询的方式，让商户和用户以最快的速度获取请求的响应结果，缩短响应时间(rt)；
18.2、基于发布订阅队列实现多节点(分布式节点)间的进程通讯，使得节点获取消息中间件最终结果的过程几乎不消耗时间；
19.3、异步转同步方式使得一次请求即可获取结果，即只需要一个往返时间(rtt)，提高了宽带利用率。
附图说明
20.附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
21.图1是本方案本发明方案与其他几种传统方案的优缺点对比示意图；
22.图2是本发明实现分布式系统多节点之间进程的通信和缩短响应时间的架构图
23.图3是本发明实现分布式系统多节点之间进程的通信和缩短响应时间的简易流程图
24.图4是本发明的实施例实现分布式系统多节点之间进程的通信和缩短响应时间的流程图。
25.图5、图6、图7为本发明与传统方案的响应时间三种场景对比示意图；
26.图8是本发明实施例的时序图。
具体实施方式
27.以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。其中附图中相同的标号全部指的是相同的部件。
28.实施例1
29.如图1-8，本发明提供一种基于发布订阅队列的异步转同步缩短响应时间的方案，在实际的生产系统中，研究发现，多数时候，上层应用收到底层服务消息中间件消息附带的处理结果快于商户来查询结果，甚至快于底层服务同步返回已受理的结果，见图5、图6和图7；
30.图5中，当获取消息中间件最终结果的时间点在返回已受理状态之前，本发明方案的响应时间《传统方案的响应时间；
31.图6中，当获取消息中间件最终结果的时间点在传统方案第一次商户查询之前，本
发明方案的响应时间《传统方案的响应时间；
32.图7中，传统方案，查询时间点恰好在最终处理结果返回之前，则需要再查第二次才能获取最终处理结果。本发明方案的响应时间《传统方案的响应时间；
33.基于此，设计了一套利用该时间差的异步转同步的解决方案。
34.包括以下技术举措，见图2和图3：
35.(1)系统同步获取中间结果后进入阻塞，等待异步最终结果通知：
36.当分布式系统(以下简称“系统”)的某个节点接收到请求时，系统组织资源开启进程a，进程a将请求转发给底层系统处理，为了用户体验，系统进程a立即返回已受理状态，注意，此时请求的处理并没有到达终态，用户仍需要等待系统处理；
37.(2)采用独立部署的发布订阅队列实现分布式多节点消息通知：
38.用户系统收到已受理状态后，不断来查询处理的最终结果，可能需要查询一到两次，甚至更多，所以表现为响应时间长。那么将系统进程a的响应改为同步响应，即系统获取已受理状态后，向独立部署的发布订阅队列订阅消息，同时进程a开始同步等待；
39.(3)利用消息中间件快速高可用的特点，发送最终结果，并触发发布订阅队列的通知：
40.系统的所有节点事先开启了进程b用来专门接收消息中间件的最终处理结果的消息，也就是说任意一个节点都可以接受消息中间件消息，然后向发布订阅队列发布消息，那么会使得上述第(2)点中的节点中处于等待状态的进程a被激活，获取到最终的处理结果，进程a直接同步响应出去，用户同步获取最终结果。最终只需要一次请求，就能获取最终结果，缩短了响应时间(rt)。
41.3个技术举措共同形成了本发明的整体特征，使得本来需要异步查询才能获取结果的方式，变成同步就能获取最终结果，3个技术举措的结合简化了异步转同步的方案。1)进程进入阻塞，同步等待，等待时间非常短，最长不超过整个一个rt时间。2)采用发布订阅队列，独立部署，不嵌入业务系统，也不需要主动清除未被激活的进程，也不需要遍历等待队列，实现方案轻巧便利。3)消息中间件与业务系统解耦，请求链路比业务系统短，所以甚至比同步响应还要快。利用这个特性实现异步转同步，比原来的响应速度快。
42.进一步的，示例如下：
43.以下结合附图4对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。其中附图中相同的标号全部指的是相同的部件
44.本发明是提供一种异步请求转同步响应的方案，解决传统方式响应时间长的问题，使得响应在尽可能短的时间内到达商家系统；
45.本发明包括以下几个模块，如图4：
46.s01、当分布式收单系统(以下简称“系统”)的节点1接收到请求时，系统组织资源开启进程a，进程a将请求转发给底层系统处理，
47.s02、系统进程a立即同步返回中间结果请求已受理状态和请求唯一标识交易号，此时请求的处理并没有到达终态，进程a用交易号作为key向发布订阅队列订阅消息，并设置超时时间为订单超时时间，队列记录了订阅消息的节点的主题和ip信息，进程a开始进入阻塞blocked，等待订阅队列发布消息，然后激活wakeup；
48.s03、系统向消息中间件发送最终处理结果消息；
49.s04、分布式部署的任意收单节点n接收消息中间件的最终处理结果的消息后，用同一个订单的交易号作为key向发布订阅队列发布消息，此时发布订阅队列发送通知唤醒节点1的进程a。进程a接收到信息调用系统原语wakeup唤醒节点1；
50.s05、节点1获取到最终的处理结果订单状态，进程a将最终结果直接同步响应出去，用户同步获取最终结果。最终只需要一次请求，就能获取最终结果，缩短了响应时间(rt)；
51.商户定时查询交易结果带来的时长问题：
52.生产上因为进程运行时点的不同，最终处理结果返回的时间也会不同，所以商户来查询的时间间隔必须够长，以避免因过短导致查询的时点落在最终处理结果返回之前，所以势必会导致查询间隔时间过长，且至少需要两个往返时间(rtt)；
53.分布式多节点中任意节点接收消息问题：
54.因为部署在生产的节点是集群部署的，每个节点都能收到消息中间件的消息，所以当某个节点接收到请求，如果要实现当前请求的节点a能获取最终处理结果并同步返回，必须要能够使得接收请求的节点a能准确收到消息中间件的消息。基于此，设计使用订阅发布队列，节点a先向队列订阅消息，任何一个节点收到消息中间件的消息后，向订阅发布队列发布消息，这时节点a收到消息后就会被激活，并同步返回最终处理结果。此时只需要一个往返时间(rtt)
55.消息中间件链路长短的问题：
56.因系统是分布式系统，采用分布式框架进行通讯，所以请求处理时间较长，但是系统的核心服务处理请求完成后，会通过消息中间件发送消息，消息不需要经过层层传递，而是可以直接被任何一个节点接收，所以消息中间件的消息传递比同步响应在理论和实际上都要快，造成接收消息的速度快于同步返回已受理状态，于是选择接收消息中间件消息作为最终处理结果的来源。
57.最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。