Sprint Boot如何基于Redis发布订阅实现异步消息系统的同步调用？

前言

在很多互联网应用系统中，请求处理异步化是提升系统性能一种常用的手段，而基于消息系统的异步处理由于具备高可靠性、高吞吐量的特点，因而在并发请求量比较高的互联网系统中被广泛应用。与此同时，这种方案也带来了调用链路处理上的问题，因为大部分应用请求都会要求同步响应实时处理结果，而由于请求的处理过程已经通过消息异步解耦，所以整个调用链路就变成了异步链路，此时请求链路的发起者如何同步拿到响应结果，就需要进行额外的系统设计考虑。

为了更清晰地理解这个问题，小码哥以最近正在做的共享单车的IOT系统为例，给大家来一张图描述下，如图所示：

在上述系统流程中，终端设备与服务端之间通过MQTT协议相连，而MQTT协议本质上是一种异步消息的连接方式，因此业务应用（如图中的订单系统）发起开锁请求后，IOT应用系统会以MQTT协议的方式通过物联网平台（此处使用的是AWS IOT服务）向设备发起开锁下行消息，而这一过程在IOT应用系统完成与物联网平台的交互后同步调用链路就结束了，因为物联网平台与锁设备之间通过MQTT消息服务异步解耦了，当然物联网平台会通过一系列可靠消息机制来确保开锁消息能够发送到指定设备的监听MQTT队列。而至于锁设备是否能够及时接收到开锁下行MQTT消息，则取决于锁设备当时的移动网络情况。

锁设备在收到MQTT开锁消息后，会通过嵌入式软件系统触发硬件设备完成开锁动作，之后就需要通过MQTT上行消息将开锁结果反馈到服务端，从而由服务端系统判断是否创建骑行订单并计算费用。这一过程需要物联网平台监听指定锁设备相应的MQTT上行消息队列，由于物联网平台需要与上万个设备进行连接，因而不可能将每一个锁设备所产生的MQTT上行消息都直接转发给Iot应用系统，因此在物联网平台可以将一类的设备MQTT消息转发至特定的业务消息队列中，例如开锁上行消息，所有设备的MQTT开锁响应上行消息都可以转发到表示开锁响应的Iot业务消息队列，如“iot_upstream_lock_response”，这样Iot业务系统则不需要再关注底层设备的MQTT消息，可以用更利于业务理解的方式去处理开锁响应结果。

现在的问题是通过MQTT协议的开锁下行消息、上行消息已经完全处于两条不同的异步网络链路，而链路的发起者此时却需要同步等待开锁结果，但是实际上同步链路早已在Iot应用系统向物联网平台发送开锁消息后就已经完成，所以为了满足调用方的同步请求/响应需要就需要在Iot应用系统的下发开锁消息后进行额外的同步阻塞等待ÿ