CN103677988B - 用于软件***的多进程通讯方法及*** - Google Patents

Abstract

本发明公开了一种用于软件***的多进程通讯方法及***。其中，该方法包括：生成进程消息；将进程消息发送至消息队列服务器；从消息队列服务器提取进程消息；对进程消息进行数据加工处理生成处理结果。通过本发明，解决了现有技术中采用统一的消息格式进行各组件进程之间的会话，耗费大量资源且会产生通信阻塞，导致***的稳定性差的问题，通过消息队列服务器实现了进程之间的会话，降低了各个进程之间的耦合性，节省***资源，增加了***的稳定性。

Description

用于软件***的多进程通讯方法及***

技术领域

本发明涉及通讯领域，具体而言，涉及一种用于软件***的多进程通讯方法及***。

背景技术

现有技术中在大型软件***的各组件进程之间统一通信的通用消息总线的实现方法，只要是设置各组件进程间的通信都必须采用的统一、规范的通用消息的格式，且以SESSION形式交互消息；同时，还要求各组件进程间通信的通用消息按照设定的路由算法进行分发。这样做具有如下两个主要缺点：通信必须采用统一规范的通用消息格式，如果软件升级扩展原有消息格式不再适用，则所有组件即便理论上未受到新格式影响都需要升级；以SESSION形式交互消息，这样消息发送方和接收方需要建立会话，在消息处理过程中双方具有强耦合的关系，这样整个***的性能被降低到性能最低的组件进程的性能水平上，对于并发计算量巨大的软件***，这会导致空耗大量操作***连接资源并可能对新的通信产生阻塞，影响***的整体处理能力。

针对现有技术中采用统一的消息格式进行各组件进程之间的会话，耗费大量资源且会产生通信阻塞，导致***的稳定性差的问题，目前尚未提出有效的解决方案。

发明内容

针对相关技术中采用统一的消息格式进行各组件进程之间的会话，耗费大量资源且会产生通信阻塞，导致***的稳定性用于软件***的多进程通讯方法及***，以解决上述问题。

为了实现上述目的，根据本发明的一个方面，提供了一种用于软件***的多进程通讯方法，该方法包括：生成进程消息；将进程消息发送至消息队列服务器；从消息队列服务器提取进程消息；对进程消息进行数据加工处理生成处理结果。

进一步地，进程消息包括消息标识，消息队列服务器包括一个或多个消息队列，其中，将进程消息发送至消息队列服务器的步骤包括：获取与消息标识对应的消息队列；将进程消息发送至消息队列。

进一步地，在对进程消息进行数据加工处理生成处理结果之后，方法还包括：将处理结果保存进键值存储数据库。

进一步地，对进程消息进行数据加工处理生成处理结果的步骤包括：判断对进程消息的处理是否成功；在对进程消息的处理成功的情况下，获取第一处理结果，其中，第一处理结果为处理成功的处理结果；在对进程消息的处理不成功的情况下，获取第二处理结果，其中，第二处理结果为处理不成功的处理结果。

进一步地，在将处理结果保存进键值存储数据库之后，方法还包括：检测键值存储数据库中是否存在与进程消息对应的处理结果；在键值存储数据库中存在与进程消息对应的处理结果的情况下，判断对进程消息的处理是否成功；在确认对进程消息处理成功的情况下，记录处理结果；在确认对进程消息处理不成功的情况下，判断是否重新发送进程消息；在确认重新发送进程消息的情况下，重新发送进程消息；在确认不重新发送进程消息的情况下，将处理结果记为错误结果；在键值存储数据库中不存在与进程消息对应的处理结果的情况下，检测是否需要等待处理结果；在需要等待处理结果的情况下，将对进程消息的处理结果记作超时结果。

进一步地，判断对进程消息的处理是否成功的步骤包括：判断处理结果是第一处理结果或者第二处理结果；在处理结果是第一处理结果的情况下，确认对进程消息处理成功；在处理结果是第二处理结果的情况下，确认对进程消息处理不成功。

为了实现上述目的，根据本发明的另一方面，提供了一种用于软件***的多进程通讯***，该***包括：发送方进程，用于生成进程消息，将进程消息发送至消息队列服务器；消息队列服务器，与发送方进程连接，用于存储进程消息；接收方进程，与消息队列服务器连接，用于从消息队列服务器中提取进程消息，并对进程消息进行数据加工处理生成处理结果。

进一步地，进程消息包括消息标识，消息队列服务器包括一个或多个消息队列，发送方进程在获取与消息标识对应的消息队列之后，将进程消息发送至消息队列。

进一步地，***还包括：键值存储数据库，与接收方进程连接，用于存储处理结果。

进一步地，键值存储数据库还与发送方进程连接，发送方从键值存储数据库中调取处理结果。

通过本发明，在发送方进程生成进程消息之后，将进程消息发送至消息队列服务器，接收方进程从该消息队列服务器提取进程消息，并对该进程消息进行处理以获取处理结果。消息发送方进程不需要与消息接受方进程建立通信链路上的连接，发送方不关心是否有接收方或具体由哪个或哪些接收方接收消息，接收方进程也不关心是哪个或哪些发送方进程发送的进程消息，这样降低了复杂的网络业务***各部分的耦合性，提升整个***的可用性和稳定性，解决了现有技术中采用统一的消息格式进行各组件进程之间的会话，耗费大量资源且会产生通信阻塞，导致***的稳定性差的问题，通过消息队列服务器实现了进程之间的会话，降低了各个进程之间的耦合性，节省***资源，增加了***的稳定性。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的用于软件***的多进程通讯***的结构示意图；

图2是根据图1所示实施例的进程消息的数据结构图；

图3是根据图1所示实施例的用于软件***的多进程通讯***的组织关系图；

图4是根据本发明实施例的用于软件***的多进程通讯方法的流程图；

图5是根据图4所示实施例的发送方进程发送进程消息的流程图；

图6是根据图4所示实施例的接收方进程接收进程消息的流程图；以及

图7是根据图4所示实施例的发送方进程获取处理结果的处理流程图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

图1是根据本发明实施例的用于软件***的多进程通讯***的结构示意图。如图1所示，该***可以包括：发送方进程10，用于生成进程消息，将进程消息发送至消息队列服务器；消息队列服务器30，与发送方进程连接，用于存储进程消息；接收方进程50，与消息队列服务器连接，用于从消息队列服务器中提取进程消息，并对进程消息进行数据加工处理生成处理结果。

采用本发明，在发送方进程生成进程消息之后，将进程消息发送至消息队列服务器，接收方进程从该消息队列服务器提取进程消息，并对该进程消息进行处理以获取处理结果。消息发送方进程不需要与消息接收方进程建立通信链路上的连接，发送方不关心是否有接收方或具体由哪个或哪些接收方接收消息，接收方进程也不关心是哪个或哪些发送方进程发送的进程消息，这样降低了复杂的网络业务***各部分的耦合性，提升整个***的可用性和稳定性，解决了现有技术中采用统一的消息格式进行各组件进程之间的会话，耗费大量资源且会产生通信阻塞，导致***的稳定性差的问题，通过消息队列服务器实现了进程之间的会话，降低了各个进程之间的耦合性，节省***资源，增加了***的稳定性。

在上述实施例中，工作进程从所属消息队列服务器提取所述进程消息后，根据实际软件***功能需求和业务需要，执行对应的数据加工操作，其中，数据加工包括：对数据的读取、截取、存储、使用消息数据触发程序内部函数或调用外部***执行的操作等等，并最终根据数据加工的处理过程的实际情况，生成处理结果。

如图2所示，进程消息的消息头可以包括消息标识，消息队列服务器包括一个或多个消息队列，发送方进程在获取与消息标识对应的消息队列之后，将进程消息发送至消息队列。

在本发明的上述实施例中，***还可以包括：键值存储数据库，与接收方进程连接，用于存储处理结果。

如图3所示，键值存储数据库还与发送方进程连接，发送方从键值存储数据库中调取处理结果。

具体地，如图3所示，该***可以包括多个消息发送方进程和多个消息接收方进程，各自与消息队列服务器和键值存储数据库建立一个连接，节约的链路层连接资源。

具体地，***可以包括多个发送方进程，发送方将特定类型的消息（即上述实施例中的进程消息）发送至消息队列服务器对应的消息队列中，一种类型的消息对应一个队列，具体地，可以通过进程消息的消息标识确定进程消息属于消息队列服务器中的消息队列，进程消息的消息标识可以首先确认该进程消息的消息类型，在确定进程消息的消息类型之后获取与该消息类型对应的消息队列；并且发送方进程发送完成后发送方不关心消息是否被接受，何时被接受，被哪个接收方进程接受，可以执行后续操作，包括继续发送新的相同或不同类型的进程消息。

如图3所示，每个接收方进程可以处理一种或多种类型的进程消息，每次从对应的消息队列中取出其可以处理的消息进行处理，处理完毕后，将处理结果写入键值存储数据库，随后再次从消息队列中取出其可以处理的消息进行处理。

图4是根据本发明实施例的用于软件***的多进程通讯方法的流程图，如图4所示该方法包括如下步骤：

步骤S102，生成进程消息。

步骤S104，将进程消息发送至消息队列服务器。

步骤S106，从消息队列服务器提取进程消息。

步骤S108，对进程消息进行数据加工处理以获取处理结果。

采用本发明，在发送方进程生成进程消息之后，将进程消息发送至消息队列服务器，接收方进程从该消息队列服务器提取进程消息，并对该进程消息进行处理以获取处理结果。消息发送方进程不需要与消息接受方进程建立通信链路上的连接，发送方不关心是否有接收方或具体由哪个或哪些接收方接收消息，接收方进程也不关心是哪个或哪些发送方进程发送的进程消息，这样降低了复杂的网络业务***各部分的耦合性，提升整个***的可用性和稳定性，解决了现有技术中采用统一的消息格式进行各组件进程之间的会话，耗费大量资源且会产生通信阻塞，导致***的稳定性差的问题，通过消息队列服务器实现了进程之间的会话，降低了各个进程之间的耦合性，节省***资源，增加了***的稳定性。

在上述实施例中，工作进程从所属消息队列服务器提取所述进程消息后，根据实际软件***功能需求和业务需要，执行对应的数据加工操作，其中，数据加工包括：对数据的读取、截取、存储、使用消息数据触发程序内部函数或调用外部***执行的操作等等，并最终根据数据加工的处理过程的实际情况，生成处理结果。

采用本发明的上述通讯方式的软件***易于升级扩展且特别适用于承担大的并发运算任务。

具体地，如图5所示，当需要发送消息给接收方处理时，发送方生成消息，送到对应的消息队列中，就可以进行后续的处理，无需等待该消息处理完毕再进行后续工作。具体地：

步骤S202：启动发送方进程发送进程消息。

然后执行步骤S102：发送方进程生成进程消息。

步骤S104：将进程消息发送至消息队列服务器。

根据本发明的上述实施例，如图2所示，进程消息可以包括消息标识，消息队列服务器包括一个或多个消息队列，其中，将进程消息发送至消息队列服务器的步骤包括：获取与消息标识对应的消息队列；将进程消息发送至消息队列。

图2所示的进程消息的数据结构还可以包括消息正文，该消息正文主要是包括需要处理的消息数据。具体地，消息体中的消息正文的格式可以是任意格式的，该进程消息的消息头中可以包含消息标识和消息类型标识，消息正文可以是任何接收方进程可以处理的格式。

根据本发明的上述实施例，在对进程消息进行数据加工处理以获取处理结果之后，方法还包括：将处理结果保存进键值存储数据库。具体地，处理结果可以基于键值的存储机制保存进存储数据库。

在本发明的上述实施例中，对进程消息进行数据加工处理以获取处理结果的步骤可以包括：判断对进程消息的处理是否成功；在对进程消息的处理成功的情况下，获取第一处理结果，其中，第一处理结果为处理成功的处理结果；在对进程消息的处理不成功的情况下，获取第二处理结果，其中，第二处理结果为处理不成功的处理结果。

具体地，在发送方进程接收消息结果反馈时，可以从键值存储数据库中根据消息标识提取处理结果，具体也可以是基于键值的存储机制来获取处理结果。当有多个接收方都提供了反馈（即处理结果）时，可以接收任意一个或多个接收方进程提供的处理结果，也即接收哪一个接收方进程反馈的行为是未定义的。

如图6所示，从消息队列获取自身能够处理的消息，加以处理，处理完成（包括成功或失败）后，将结果写入键值存储数据库，随后再取出一条自身能够处理的消息进行处理。具体地可以通过如下步骤实现：

步骤S302：启动接收方进程接收过程消息。

步骤S106：接收方进程从消息队列服务器提取进程消息。

其中，具体地，接收方进程从消息队列服务器对应的消息队列中读取或提取一条进程消息。每个接收方进程可以处理的进程消息的消息类型可以是预先设定的，可以通过预先设定的消息类型获取对应的消息队列中的进程消息。

步骤S304：对提取到的进程消息进行相应的处理。此处相应的处理是在进程消息的消息正文里携带的内容确定的，该处理可以是读取数据、修改数据或者计算数据。

步骤S306：判断对进程消息的处理是否成功。其中，在处理成功的情况下，执行步骤S308；在处理不成功的情况下，执行步骤S310。

具体地，对进程消息的处理不成功有两大类：一是来自接收方进程依存的软件和硬件***本身的***层面的错误或限制导致无法成功处理的情况，例如存储设备用尽、对必要接口的访问超时等错误，我们称为***错误；另一类是根据实际软件***功能需求和业务需要认定的错误，例如支付处理过程发现余额不足等业务层面的问题，我们称之为业务错误。***错误一般由捕获***层面的异常信号获取，业务错误则由接收方程序根据业务需要进行判断。

步骤S308：向键值数据库写入第一处理结果。该第一处理结果中携带着对进程消息处理成功的信息。

步骤S310：向键值数据库写入第二处理结果。该第二处理结果中携带着对进程消息处理不成功的信息。

如图5所示，在本发明的上述实施例中，在将处理结果保存进键值存储数据库之后，方法还可以包括：检测键值存储数据库中是否存在与进程消息对应的处理结果；在键值存储数据库中存在与进程消息对应的处理结果的情况下，判断对进程消息的处理是否成功；在确认对进程消息处理成功的情况下，记录处理结果；在确认对进程消息处理不成功的情况下，判断是否重新发送进程消息；在确认重新发送进程消息的情况下，重新发送进程消息；在确认不重新发送进程消息的情况下，将处理结果记为错误结果；在键值存储数据库中不存在与进程消息对应的处理结果的情况下，检测是否需要等待处理结果；在需要等待处理结果的情况下，将对进程消息的处理结果记作超时结果。

根据本发明的上述实施例，判断对进程消息的处理是否成功的步骤可以包括：判断处理结果是第一处理结果或者第二处理结果；在处理结果是第一处理结果的情况下，确认对进程消息处理成功；在处理结果是第二处理结果的情况下，确认对进程消息处理不成功。

具体地，如图7所示，当需要了解消息处理结果时，这可以由发送方进程内部的时序处理机制或外部的信号机制触发，发送方进程访问键值存储数据库以了解消息是否处理完毕以及是否成功处理。并根据业务需要对处理结果进行相应的操作。具体地可以通过如下方法实现：

步骤S401：从键值数据库中获取处理结果。

步骤S402：检测键值存储数据库中是否存在与进程消息对应的处理结果。如果存在执行步骤S403，如果不存在执行步骤S404。

步骤S403：判断对进程消息的处理是否成功。在对进程消息成功的情况下，执行步骤S405，在对进程消息处理不成功的情况下，执行步骤S406。

步骤S404：检测是否需要等待处理结果。在需要等待处理结果的情况下，执行步骤S409；在不需要等待处理结果的情况下，执行步骤S410。

具体地，发送方进程在最初发出消息时，根据消息内容的性质，对需要多长时间能够得到结果即存在预期，也即发送方进程发送进程消息时携带了响应时间，该响应时间即为上述实施例中提及的期冀得到处理结果的时间，该允许的等待时间（即响应时间）根据实际情况可能从数百毫秒到数小时或更长，更具体地，发送方进程可根据实际情况自行保存响应时间的配置。

步骤S405：记录处理结果。

步骤S406：判断是否重新发送进程消息。其中，在是的情况下，执行步骤S407；在否的情况下，执行步骤S408。

具体地，根据消息处理不成功的具体情况以及实际软件***功能需求和业务需要，消息发送方可以决定是否需要重新发送进程消息，或者是根据业务需要完成额外的步骤（例如发送其它消息）来满足成功处理的条件后再次发送之前的进程消息。

步骤S407：重新发送进程消息。

步骤S408：将处理结果记为错误结果。

步骤S409：将对进程消息的处理结果记作超时结果。

步骤S410：不做处理等下次再次进入获取消息处理结果的过程。

发送方在适当的时候从键值存储数据库根据最初的消息标识获取消息的处理结果。如果该结果不存在，可以根据业务需要决定延迟适当的时间再次获取，或者认为处理超时。如果结果是一个错误信息，可以根据业务需要决定重新发送消息，或者接受该结果作为处理异常。

在本发明的上述实施例中，在***中设置基于AMQP协议的消息队列服务器以及键值存储数据库；一个进程（发送方进程或接收方进程）只需要与消息队列服务器和键值存储数据库建立唯一的一个链路层连接。采用上述方法，降低的组件进程之间的耦合程度，如果软件***需要升级扩展，只有受影响的进程需要升级，其它未受影响的进程无需进行任何调整。同时，发送方进程与接收方进程不存在一一对应的强连接关系，对于性能较高的组件可以布署较少的进程，对于性能较低的组件可以布署较多的进程，有效利用物理资源。并且，在本发明的上述实施例中，不对消息的格式进行统一规范，通过消息队列服务器特定类型的消息总是被能够处理该消息的接收方进程接收，特别适合业务需求不断更新的软件***。同时，不使用SESSION而是使用键值存储数据库异步接收处理结果，允许通过按需布署不同的进程提升整体***的并发处理能力。

更具体地，使用AMQP发布消息，发布消息时可以指定接收反馈的键，可以通过键值存储设备（即键值数据库）获取0个或1个反馈（即处理结果）。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

从以上的描述中，可以看出，本发明实现了如下技术效果：采用本发明，在发送方进程生成进程消息之后，将进程消息发送至消息队列服务器，接收方进程从该消息队列服务器提取进程消息，并对该进程消息进行处理以获取处理结果。消息发送方进程不需要与消息接受方进程建立通信链路上的连接，发送方不关心是否有接收方或具体由哪个或哪些接收方接收消息，接收方进程也不关心是哪个或哪些发送方进程发送的进程消息，这样降低了复杂的网络业务***各部分的耦合性，提升整个***的可用性和稳定性，解决了现有技术中采用统一的消息格式进行各组件进程之间的会话，耗费大量资源且会产生通信阻塞，导致***的稳定性差的问题，通过消息队列服务器实现了进程之间的会话，降低了各个进程之间的耦合性，节省***资源，增加了***的稳定性。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种用于软件***的多进程通讯方法，其特征在于，包括：

生成进程消息，其中，所述进程消息包括消息头和消息正文，所述消息正文包括需要处理的消息数据；

将所述进程消息发送至消息队列服务器；

接收方进程从所述消息队列服务器提取所述进程消息；

对所述进程消息进行数据加工处理生成处理结果,

其中，通过发送方进程生成所述进程消息，

其中，在对所述进程消息进行数据加工处理生成处理结果之后，所述方法还包括：将所述处理结果保存进键值存储数据库，使用所述键值存储数据库异步接收处理结果，并按需布署不同的进程，

其中，所述发送方进程与所述消息队列服务器以及所述键值存储数据库三者之间建立唯一的链路层连接，或者，所述接收方进程与所述消息队列服务器以及所述键值存储数据库三者之间建立唯一的链路层连接。

2.根据权利要求1所述的方法，其特征在于，所述进程消息包括消息标识，所述消息队列服务器包括一个或多个消息队列，其中，将所述进程消息发送至消息队列服务器的步骤包括：

获取与所述消息标识对应的消息队列；

将所述进程消息发送至所述消息队列。

3.根据权利要求1所述的方法，其特征在于，对所述进程消息进行数据加工处理生成处理结果的步骤包括：

判断对所述进程消息的处理是否成功；

在对所述进程消息的处理成功的情况下，获取第一处理结果，其中，所述第一处理结果为处理成功的处理结果；

在对所述进程消息的处理不成功的情况下，获取第二处理结果，其中，所述第二处理结果为处理不成功的处理结果。

4.根据权利要求3所述的方法，其特征在于，在将所述处理结果保存进键值存储数据库之后，所述方法还包括：

检测所述键值存储数据库中是否存在与所述进程消息对应的所述处理结果；

在所述键值存储数据库中存在与所述进程消息对应的所述处理结果的情况下，判断对所述进程消息的处理是否成功；

在确认对所述进程消息处理成功的情况下，记录所述处理结果；

在确认对所述进程消息处理不成功的情况下，判断是否重新发送所述进程消息；

在确认重新发送所述进程消息的情况下，重新发送所述进程消息；

在确认不重新发送所述进程消息的情况下，将所述处理结果记为错误结果；

在所述键值存储数据库中不存在与所述进程消息对应的所述处理结果的情况下，检测是否需要等待所述处理结果；

在需要等待所述处理结果的情况下，将对所述进程消息的处理结果记作超时结果。

5.根据权利要求4所述的方法，其特征在于，判断对所述进程消息的处理是否成功的步骤包括：

判断所述处理结果是所述第一处理结果或者所述第二处理结果；

在所述处理结果是所述第一处理结果的情况下，确认对所述进程消息处理成功；

在所述处理结果是所述第二处理结果的情况下，确认对所述进程消息处理不成功。

6.一种用于软件***的多进程通讯***，其特征在于，包括：

发送方进程，用于生成进程消息，将所述进程消息发送至消息队列服务器,其中，所述进程消息包括消息头和消息正文，所述消息正文包括需要处理的消息数据；

所述消息队列服务器，与所述发送方进程连接，用于存储所述进程消息；

接收方进程，与所述消息队列服务器连接，用于从所述消息队列服务器中提取所述进程消息，并对所述进程消息进行数据加工处理生成处理结果，

其中，所述***还包括：键值存储数据库，与所述接收方进程连接，用于存储所述处理结果，使用所述键值存储数据库异步接收处理结果，并按需布署不同的进程，

其中，所述发送方进程与所述消息队列服务器以及所述键值存储数据库三者之间建立唯一的链路层连接，或者，所述接收方进程与所述消息队列服务器以及所述键值存储数据库三者之间建立唯一的链路层连接。

7.根据权利要求6所述的***，其特征在于，所述进程消息包括消息标识，所述消息队列服务器包括一个或多个消息队列，所述发送方进程在获取与所述消息标识对应的消息队列之后，将所述进程消息发送至所述消息队列。

8.根据权利要求7所述的***，其特征在于，所述键值存储数据库还与所述发送方进程连接，所述发送方进程从所述键值存储数据库中调取所述处理结果。