一种面向多进程异步并发通讯方法

2021-11-08田丰王海杨国胜韦强

电脑知识与技术 2021年27期

关键词：通讯

田丰王海杨国胜韦强

摘要：为了应对民航业务扩展、业务复杂度增加的趋势，分析了当前常见的多线程通讯方式，提出一种基于共享内存的多进程纯异步通信方法。建立快速、可靠、可扩展、可独立部署并完全托管的消息队列服务，在保障传输可靠性、数据一致性的情况下，降低子系统间的耦合度，实现系统间的高效通信。通过部署少量进程就可以提供系统的吞吐量，降低交易响应时间。

关键词：多进程;异步;并发;通讯

中图分类号：TP319 文献标识码：A

文章编号：1009-3044（2021）27-0064-04

1 背景

随着民航业务板块的扩张、业务服务的增加、互联网技术的发展，企业系统平台逐步根据服务内容由集中的单体系统拆分成多个子业务系统。相较于集中式单体系统中模块间的数据交互，子业务系统间交互更为复杂，在业务处理过程中，往往需要各业务系统之间分工合作，访问各子系统对外开放接口获取信息[1]。因此，对系统数据传输的吞吐量及可靠性也有了更高的要求。

2 多进程通讯现状

大部分的业务系统为保障数据的一致性，满足各业务系统间合作的需求，子系统间通常通过RPC同步调用服务，但在某些场景中，RPC同步调用的响应时间较长，造成资源的浪费，系统吞吐量下降。以AV航信查询系统为例：当用户要查询北京到洛杉矶的航班时，AV系统需要同时访问Delta、Southwest航空公司的航班信息，整合后返回给调用方。如图所示：

假设业务处理时间为0秒，Delta响应时间为2秒，Southwest响应为3秒。那么，一个请求的响应时间为5秒。我们系统的最大并发量为3个请求，那么当并发请求数大于3时，剩余的请求只能堆积在消息队列中。其次，3个进程需要花费5秒的时间在等待應答，并且不做任何其他事情。这将导致系统的吞吐量遇到瓶颈，且系统的CPU、内存使用率低。由此可见，RPC服务调用虽然能够满足实时调用的业务场景，但针对上述异步、业务操作复杂的场景，业务系统的性能目标无法满足。

为了提高吞吐量、降低响应时延，现有技术提出了通过增加进程个数来提高吞吐量的半同步通讯方式。该方式是在上述方案的基础上进行的改进，将两次同步调用变为异步调用[2]。可以同时发送两个请求，再获取应答。

如上图所示，这种方案的处理时间取决于外部系统的最大响应时间，即3秒。

然而，这种优化方案依然存在问题。首先，这种方案无法提前预估并发量。高峰期时并发量大，而低峰期时并发量很少。而在低峰期部署大量的处理进程反而会导致资源的浪费[3]。“部署多少进程合适？”的问题依然没有得到解决[4]。其次，进程在等待应答的3秒过程依然无法处理其他请求，意味着其他请求依然需要排队。

3 多进程异步并发通讯设计

针对上述现有技术的问题，本文提出一种基于共享内存的多进程纯异步通信方法，抽取进程状态并存储于在传输过程中动态创建的共享内存组件存储中，释放无状态进程的等待时间，建立快速、可靠、可扩展、可独立部署并完全托管的消息队列服务，在保障传输可靠性、数据一致性的情况下，降低子系统间的耦合度，实现系统间的高效通信。一方面部署少量进程即可以增加吞吐量，另一方面在等待异步应答的过程中依然可以响应其他交易请求。

3.1 系统组成

面向多进程的纯异步通信装置由服务消费方、异步消息交互服务和服务提供方组成。其中异步消息交互服务分为4个组件，分别是数据接入服务组件、消息队列组件、异步通信进程池和共享内存组件。

数据接入服务组件：负责接受服务消费方各种形式的并发连接请求，并将请求放到对应的消息队列中。

消息队列组件：面向流量峰值的处理方案，当消息涌入时，首先将请求或异步应答存放入消息队列中，再根据流量控制策略进行后续处理。

异步通信进程池：每个进程有一个I/O线程，负责与服务提供方进行直接通信，根据消息中的参数信息，与对应的主服务端或从服务端建立连接、异步发送相关消息，接收服务提供方的应答结果，并存放至消息队列中。

共享内存组件：共享内存组件在数据交互的过程中动态创建异步交互上下文，根据业务特征存储某组数据交互的上下文，及中间结果。

3.2 实现原理

面向多进程的纯异步通信方法在整个交易过程中采用完全异步的方式，没有任何阻塞点。在进程发起异步请求后，进程并不等待，而是继续处理其他请求;当异步应答回来后，再通过读取上下文，恢复现场，继续处理上次交易。

具体进程处理过程如下图所示：

步骤1. http接入收到请求后将请求放入消息队列

步骤2. 进程读取消息队列后，

1）如当前消息属性为请求，则生成全局交易号，保存原始请求报文，应用需要暂存的kv数据，以及要等待的异步应答个数等上下文数据，发起异步调用，转步骤2。