CN203574673U - 一种消息处理系统 - Google Patents

Abstract

本实用新型提供一种消息处理系统，所述系统包括客户端，与所述客户端连接的消息总线以及与所述消息总线连接的任务处理器；以及消息机制，用于将所述消息包缓存在本地服务器，通过序列化的方式将所述消息包存储于磁盘中，通过高效的读写机制访问所述消息包。其中，所述消息总线包括监听器、中转站以及路由器。本技术方案提高了可靠性的同时提高了工作效率。

Description

一种消息处理系统

技术领域

本实用新型涉及信息处理领域，尤其涉及一种消息处理系统。

背景技术

在医疗系统中，系统传输的信息可能是患者的诊疗数据，与患者的生命安全息息相关。如何在不稳定的环境下(如网络中断、网络繁忙、服务器宕机等)，提供稳定的消息服务，保证消息包和软件系统的高可靠性，是一项具有挑战性的工作。

传统的消息处理模型分为发送方和接收方，发送方是消息的来源，接收方接收来自发送方的消息包，是一对一的关系。它们之间消息传递是通过网络传输协议同步进行的，发送方发出数据后，等待接收方发回响应以后才发下一个数据包，而网络常常是不稳定的，在带宽不够、网络繁忙、网络中断时，会发生发送方发送了消息包，而接收方并没有收到消息包时，这时系统的发送方和接收方都会等待对方的结果，相互阻塞，只有接收到结果消息包后才往下继续处理其他的消息。此外，消息的发送方和接收方由于各自的处理任务的能力不一致也会出现相互等待的情况。这样，长时间的相互等待会影响系统性能，在大量消息并发阻塞时会导致系统崩溃。

一种改进方式是采用分布式消息处理模型，它通过采用消息队列把消息缓存在内存中来保证本地消息不丢失，在网络不稳定或者中断时，如果出现消息包丢失，则不停地重发此消息包直到成功，来保证消息的可靠传输。但是，当整个分布式集群的缓存服务器死机或者内存故障时，还是会出现消息的丢失，即使重启机器也无法恢复原有的消息包，降低了系统的安全性。

实用新型内容

本实用新型解决的问题是提供方法一种消息处理系统，不仅具有高可靠性，还提高了工作效率。

为了解决上述问题，本实用新型提供了一种消息处理系统，包括括客户端，与所述客户端连接的消息总线以及与所述消息总线连接的任务处理器。

上述所述一种消息处理系统，其中，所述客户端、消息总线以及任务处理器之间的传递为消息包。

上述所述一种消息处理系统，其中，所述消息包包括请求消息包和结果消息包。

上述所述一种消息处理系统，其中，所述请求消息包的格式包括业务状态、状态标识和业务数据。

上述所述一种消息处理系统，其中，所述结果消息包的格式包括业务编码、状态标识和结果信息。

上述所述一种消息处理系统，其中，所述系统具有消息机制，用于将所述消息包缓存在本地服务器，通过序列化的方式将所述消息包存储于磁盘中，通过高效的读写机制访问所述消息包。

上述所述一种消息处理系统，其中，所述消息总线包括监听器、中转站以及路由器。

上述所述一种消息处理系统，其中，所述中转站与磁盘连接。

上述所述一种消息处理系统，其中，所述路由器通过心跳机制与所述任务处理器连接。

与现有技术相比，本实用新型把系统解耦成客户端、消息总线和任务处理器三个独立的模块，每个模块提供独立的消息服务，当任意一个模块中暂时，不会影响其它模块提供消息服务，在保证消息处理系统可靠性的同时也提高了其工作效率；

进一步地，采用消息机制确保消息包在各个模块的传统中不会丢失，使得消息处理系统具有高可靠性；

进一步地，通过把消息总线模块接收的请求消息包实时写入磁盘，当服务器宕机现象恢复之后，可从磁盘文件中恢复消息包继续工作，使得消息处理系统具有自我恢复能力。

附图说明

图1所示为本实用新型实施例一种消息处理系统的结构示意图；

图2所示为本实用新型实施例请求消息包的结构示意图；

图3所示为本实用新型实施例结果消息包的结构示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本实用新型。但是本实用新型能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本实用新型内涵的情况下做类似推广，因此本实用新型不受下面公开的具体实施的限制。

其次，本实用新型利用示意图进行详细描述，在详述本实用新型实施例时，为便于说明，所述示意图只是实例，其在此不应限制本实用新型保护的范围。

下面结合附图和实施例对本实用新型一种消息处理系统进行详细地说明。本实用新型实施例消息处理系统如图1所示，所述消息处理系统包括客户端1，与所述客户端1连接的消息总线2以及与所述消息总线2连接的任务处理器3。其中，所述客户端、消息总线以及任务处理器之间的传递为消息包，所述消息包包括请求消息包和结果消息包。具体地，在本实施例中，首先，用户通过客户端1提交所述请求消息包给消息总线2。其中，所述请求消息包的格式如图2所示，包括头信息和业务数据，头信息包括业务名称和状态标识。业务名称指的是请求需要的业务名称，代理会根据业务名称从路由表中查找相应的任务处理器来处理相应的业务需求；状态标识有已发送和未发送，当把此消息成功发送给请求线程后，会改写为已发送，否则标识成未发送；业务数据是用户需要处理的业务数据，如查询消息时需要的查询条件。

此外，所述系统具有消息机制，用于将所述消息包缓存在本地服务器，通过序列化的方式将所述消息包存储于磁盘中，通过高效的读写机制访问所述消息包。客户端采用多线程先进先出的方式读取消息队列。具体地，客户端使用消息队列，把消息包缓存在本地，及时消息总线出现暂时不可达的情况(如网络突然中断、宕机等)，客户端也能在消息总线回复正常后，继续提交消息包，保证整个消息处理系统的高可用性。用户通过客户端将消息包写入请求消息队列，再通过请求线程将消息按照缓存顺序逐个发给消息总线，如果收到消息总线返回的是发送成功应答，则对该消息包进行标识，不再发送；如果在指定时间内没有应答到达(指定时间T＝1秒)，则重新发送，如果多次重发之后，还是没有应答，则对该消息包进行标识，并把失败原因返回给用户，用户可选择放弃发送该消息，也可以选择继续重发消息包。需要说明的是，在本实施例中，多次重发的次数为10次。

接着，消息总线2接收客户端1发送的请求，指派任务请求给任务处理器3处理任务。所述消息总线包括监听器21、中转站22以及路由器23。为了保证在消息总线死机时不丢失数据，消息总线支持自动回复功能。消息总线中的中转站将接收到的客户端请求的消息包实时写入磁盘文件4。如果消息总线宕机，当宕机现象恢复之后，消息总线可以从磁盘文件中重新获得消息包，继续为客户端和任务处理器提供消息服务。具体地，在本实施例中，消息总线2中的监听器21接收来自客户端的请求消息包。监听器获得客户端的请求消息后，首先查找监听列表中是否含有客户端地址，如果没有，则把客户端IP地址和端口号加入监听列表中，监听器会把此任务提交给中转站22。中转站22把监听器21提交的请求消息包写入磁盘文件中，解析请求消息包，并提交请求消息包给路由器23处理。具体地，中转站通过先进先出的方式解析消息包获得业务名称，并把业务名称发送给路由器。

路由器23匹配请求消息包的任务名称(即服务名称)和任务处理器，把请求消息包发送给相应的任务处理器3，并异步等待接收任务处理器返回的结果消息包。路由器中存储了所有的任务处理器的服务地址表，路由器通过心跳机制与任务处理器保持联系，当路由器超过一定时间不能接收到来自任务处理器的心跳消息包，则认定此任务处理器失效，更新路由列表把此服务设置为失效状态。路由器接收来自中转站的服务请求，根据具体的业务类型在服务映射表中查找任务处理器，当查找到此任务处理器后，路由器会把消息包转发给任务处理器。需要说明的是，服务名称需在路由器中注册。

接着，任务处理器3接收来自路由器的请求消息包，进行业务逻辑的处理，完成后把结果消息包返回给路由器。所述结果消息包的格式如图3所示，包含头信息和结果信息，头信息包括业务编码和状态标识。业务编码对客户端无实际的意义，是消息总线统一分配的消息包标识编码，目的是跟踪消息包，方便调试；状态标识有“成功”、“失败”以及“异常”，“成功”表示任务处理器已经成功处理此消息，“失败”表示处理此消息失败，“异常”表示消息包处理遇到问题，如查询条件不符合规范；结果信息中包含了任务处理器处理此请求后的结果信息，如查询消息时查询到的信息列表。

任务处理器定时发送心跳包给路由器，告知自己在线，并实时监听并接收到来自路由器发送的请求消息包，并将其保存在请求消息队列中。任务处理器后台的多线程从队列中读取请求消息包，对其进行处理，处理完成后生成结果消息包，并保存到结果消息队列中。任务处理器把结果消息队列中的结果消息包异步多线程发送给路由器。

路由器通过异步回调的方式获得任务处理器返回的结果，并把结果返回给中转站，中转站通过监听器把结果消息包返回给客户端，如果发送失败，则会不停地重试发送，直至成功；当查找不到相应的任务处理器，路由器会告知中转站不能查找到相应的任务处理器，中转站同时会把错误信息通过监听器发送给客户端。需要说明的是，当中转站成功接收到路由器返回的结果，且收到客户端发送的任务处理完成的确认消息包，才能把对应的请求消息包从磁盘文件中删除，否则该请求消息包会一直保留在磁盘文件中。

当客户端接收到结果信息包后，把结果信息包放入结果消息队列中，用户可从此队列中获取返回的结果。需要说明的是，客户端需要绑定消息总线地址，并通过后台轮询线程异步取得返回的结果。客户端发送完本地队列中所有的请求包后，不需要同步等待消息总线处理完的返回结果，而是利用后台轮询线程异步接收来自消息总线的返回结果信息包。从而在保证系统高可靠性的同时也提高了工作效率。

本实用新型虽然已以较佳实施例公开如上，但其并不是用来限定本实用新型，任何本领域技术人员在不脱离本实用新型的精神和范围内，都可以利用上述揭示的方法和技术内容对本实用新型技术方案做出可能的变动和修改，因此，凡是未脱离本实用新型技术方案的内容，依据本实用新型的技术实质对以上实施例所作的任何简单修改、等同变化及修饰，均属于本实用新型技术方案的保护范围。

Claims (9)

1.一种消息处理系统，其特征在于，包括客户端；与所述客户端连接的消息总线，通过所述消息总线中的监听器接收所述客户端的消息包以及与所述消息总线连接的任务处理器，通过所述消息总线中的路由器将所述消息包传递给所述任务处理器。 

2.如权利要求1所述一种消息处理系统，其特征在于，所述客户端、消息总线以及任务处理器之间的传递为消息包。 

3.如权利要求2所述一种消息处理系统，其特征在于，所述消息包包括请求消息包和结果消息包。 

4.如权利要求3所述一种消息处理系统，其特征在于，所述请求消息包的格式包括业务状态、状态标识和业务数据。 

5.如权利要求3所述一种消息处理系统，其特征在于，所述结果消息包的格式包括业务编码、状态标识和结果信息。 

6.如权利要求1所述一种消息处理系统，其特征在于，所述系统具有消息机制，用于将所述消息包缓存在本地服务器，通过序列化的方式将所述消息包存储于磁盘中，通过读写机制访问所述消息包。 

7.如权利要求1所述一种消息处理系统，其特征在于，所述消息总线包括监听器、中转站以及路由器。 

8.如权利要求7所述一种消息处理系统，其特征在于，所述中转站与磁盘连接。 

9.如权利要求7所述一种消息处理系统，其特征在于，所述路由器通过心跳机制与所述任务处理器连接。 

Images