CN105338086A - 一种分布式的消息转发方法 - Google Patents

Abstract

本发明公开了一种分布式的消息转发方法，属于数据交互服务领域。该方法以分布式管理工具Zookeeper实现各转发服务器间的配置同步以及状态管理，每个转发服务器都作为Zookeeper集群中的一个节点，每个转发服务器节点对其他转发服务器的状态进行监控，当其他转发服务器节点状态发生变化时，通过负载均衡算法，对发生变化的转发服务器任务进行重新分配。与现有技术相比，本发明方法提供了订阅/发布功能，实现消息的按需定制；各转发服务器互为主备，保证任意一台转发服务器崩溃后不影响服务的正常运行；对转发失败消息进行持久化存储，保证数据的安全性；对高并发、批量数据进行条件性序列化缓存，保证了服务运行的稳定性。

Description

一种分布式的消息转发方法

技术领域

本发明涉及数据交互服务领域，具体地说是一种分布式的消息转发方法。

背景技术

消息队列是一种系统与系统之间的通信方法。系统通过写和检索出列队的数据(消息)来通信，而无需专用连接来链接它们。通过消息队列，系统可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。

消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。消息队列的接口调用被嵌入到新的或现存的应用中，通过消息发送到内存或基于磁盘的队列或从它读出而提供信息交换。消息队列可用在应用中以执行多种功能，比如要求服务、交换信息或异步处理等。

现有技术中存在的分布式消息队列，如Kafka、MetaQ，满足了对吞吐量、高并发任务处理的需求，但受限于其开发语言、应用场景等，对部分功能的支持并不完善。Kafka采用Scala进行开发，整个Scala社区的发展比较缓慢，且不支持事务、消息异步发送、消息广播等处理机制。MetaQ采用Java语言在Kafka基础上进行重新开发，扩展了事务支持、消息异步发送、消息广播等机制，但在消息顺序性及优先级方面没有较好的解决方案。

发明内容

本发明的技术任务是针对上述现有技术的不足，提供一种分布式的消息转发方法。该方法在实现现有技术相关产品功能的基础上，对消息的顺序性、优先级、高可用、可持久化等方面提供有效的解决方案。

本发明的技术任务是按以下方式实现的：一种分布式的消息转发方法，其特点是以分布式管理工具(Zookeeper)实现各转发服务器间的配置同步以及状态管理，每个转发服务器都作为Zookeeper集群中的一个节点，每个转发服务器节点对其他转发服务器的状态进行监控，当其他转发服务器节点状态发生变化(新增转发节点或者现有转发节点崩溃)时，通过负载均衡算法，对发生变化的转发服务器任务进行重新分配；并且，将分布式消息服务接口作为Zookeeper集群节点的一部分，每个接口库作为Zookeeper集群的一个临时节点，接口库内部通过监视服务获取转发服务器地址信息及状态信息，以选择所需的转发服务器；所述分布式消息服务接口包括订阅端接口和发布端接口，订阅端接口用于提交订阅请求；发布端接口用于发布任务处理数据。

上述方法中，Zookeeper集群对各转发服务器信息进行统一管理，并进行发布，订阅端和发布端节点可通过访问转发服务器节点目录，获取所有转发服务器的地址信息及状态信息等。各订阅端节点、发布端节点通过负载均衡模式或配置模式选择可以使用的转发服务器进行数据转发。

数据转发服务是实现上述方法的主体模块，该模块可以实现的功能包括：获取服务转发地址信息、消息解析、消息分发(包括订阅请求的转发和订阅数据的转发)、相同请求处理、特殊订阅处理(过滤处理)以及订阅信息注册及取消订阅。

数据转发任务到达某一转发服务器后，该转发服务器获取该任务的哈希码，根据哈希码将该转发任务通过系统内部高速通道，将其转发到相应的处理服务器进行处理。集群内部各转发服务器之间优选通过socket长连接进行通信，保证转发服务器间的高速数据同步。当某一转发服务器崩溃时，触发系统内部的负载均衡算法，将崩溃转发服务器的转发任务重新分配给其他转发服务器，保证数据不丢失及服务的正常运行。转发服务器数据转发服务具体实现流程为：

一、初始化运行环境，获取服务转发配置信息，包括服务类型、服务提供方地址、采用的通信方式以及服务自动探测周期，配置信息记录到服务转发表中；

二、数据转发服务接收消息；

三、数据转发服务对消息进行解析，获取消息哈希码，并根据哈希码转发到相应的处理服务器；

四、数据处理服务器对消息进行解析，获取消息类型以及消息服务码，并根据消息类型及服务码进行相应的处理。

当转发服务器对服务存在内存使用限制时，采用序列化技术对内存任务队列进行优化：当内存中的数据量达到预设内存大小时，将后续接收到的消息进行序列化处理；当内存中的任务处理完毕后者达到某一规定的阈值后，将序列化文件中的消息反序列化入内存任务队列中进行处理。序列化格式可采用如下结构：

消息类型(1个字节)+报文头长度(2个字节)+报文头内容+数据块长度(4个字节)+数据块内容+文件名长度(2个字节)+文件名。

当接收到事务类型转发任务时，如果事务中各子任务之间没有顺序要求，或者只存在局部顺序性要求，则事务将被拆分为多个小块任务进行处理，各小块任务可能经由其他转发服务器转发处理；各小块任务的处理结果最终汇集到初始接收任务转发服务器，由该服务器服务将各小块任务结果进行汇总，并最终反馈给事务请求提交者。

相同优先级的数据转发任务按照转发服务器接收到的顺序进行转发，高优先级的任务根据优先等级顺序发送。

某一订阅端(或发布端)发送到转发服务器的多个子任务，如果子任务之间存在顺序要求，则按照顺序进行转发，某一子任务失败，将导致整个任务的失败。多个订阅端(或者发布端)之间的任务顺序没有要求。任何一个小块任务的失败将导致整个任务的失败。

数据转发任务在转发失败后，分布式消息队列将失败任务进行本地持久化存储，并在其生命周期内进行尝试重发，发送成功或者生命周期结束后，再将失效数据进行清理。

步骤四中所述基本消息类型包括：请求消息、响应消息、取消订阅消息以及探测消息；

如果接收到的消息类型是请求消息，并且注册列表中没有该类型的请求，或者请求参数不相同，则根据服务转发表将消息转发给相应的服务提供方，并将该订阅信息同步到MASTER服务器，MASTER触发各转发服务器之间的订阅同步功能，将订阅列表同步；另外，如果已有该类型的请求，但超过某个时间阀值未收到响应，数据转发服务将重发该订阅请求；

如果是响应消息，则根据服务码以及注册列表将消息返回给相应的订阅者；数据回返时根据注册列表中的过滤条件选择回返方式，回返方式可自定义；

如果是取消订阅消息，则将该订阅者从注册列表中删除，当注册列表为空时，数据转发服务将向该类型的消息服务提供方发送取消订阅消息；

如果是探测消息，则提示服务提供方正常运行，并根据业务需求进行相关处理。

与现有技术相比，本发明的分布式的消息转发方法具有以下有益效果：

(一)支持高并发、大批量数据转发任务，网络正常情况下，转发延迟控制在毫秒级别；

(二)高稳定性：各转发服务器互为主备，保证在任意一台转发服务器崩溃后，服务能够正常有效运行。当内存占用量达到预设阈值时，采用序列化缓存技术对后续任务进行序列化处理，避免系统对内存的持续增长性占用，保证服务的稳定运行；

(三)顺序性：相同优先级情况下，保证转发任务按照转发服务器的接收顺序进行转发；高优先级的任务优先处理；

(四)高扩展性：分布式消息队列系统内部各转发服务器地位相同，可根据需求任意扩展。提供发订阅/发布标准接口，各服务能够按需动态加载、卸载。

附图说明

附图1是本发明分布式的消息转发方法的逻辑图；

附图2是实施例一中数据转发服务类图。

具体实施方式

参照说明书附图以具体实施例对本发明的分布式的消息转发方法作以下详细地说明。

实施例：

本发明分布式消息转发方法的实现包括：分布式消息队列服务、分布式消息服务接口。

(一)分布式消息队列服务

(1)分布式框架

如附图1所示，分布式消息队列借助分布式管理工具Zookeeper实现各转发服务器间的配置同步以及状态管理，每个转发服务器都是Zookeeper集群中的一个节点(称为znodeServer)，每个转发服务器节点对其他转发服务器的状态进行监控，当其他转发服务器节点状态发生变化(新增转发节点或者现有转发节点崩溃)时，触发负载均衡算法，对发生变化的转发服务器任务进行重新分配。

Zookeeper集群对各转发服务器信息进行统一管理，并进行发布，订阅端和发布端节点可通过访问转发服务器节点目录，获取所有转发服务器的地址信息及状态信息等。各订阅端节点、发布端节点通过负载均衡算法选择可以使用的转发服务器进行数据转发。

(2)数据转发服务

数据转发服务是消息队列的主体模块，该模块需要实现的功能包括：获取服务转发地址信息、消息解析、消息分发(包括订阅请求的转发和订阅数据的转发)、相同请求处理、特殊订阅处理(过滤处理)以及订阅信息注册及取消订阅。

数据转发服务具体实现流程为：

(A)初始化运行环境，获取服务转发配置信息，包括服务类型、服务提供方地址、采用的通信方式以及服务自动探测周期，配置信息记录到服务转发表中；

(B)数据转发服务接收消息；

(C)数据转发服务对消息进行解析，获取消息哈希码，并根据哈希码转发到相应的处理服务器。

(D)数据处理服务器对消息进行解析，获取消息类型以及消息服务码，并根据消息类型及服务码进行相应的处理。基本消息类型包括：请求消息、响应消息、取消订阅消息以及探测消息，消息类型可根据业务需要进行扩展。如果接收到的消息类型是请求消息，并且注册列表中没有该类型的请求，或者请求参数不相同，则根据服务转发表将消息转发给相应的服务提供方，并将该订阅信息同步到MASTER服务器，MASTER触发各转发服务器之间的订阅同步功能，将订阅列表同步；另外，如果已有该类型的请求，但超过某个时间阀值未收到响应，数据转发服务将重发该订阅请求。如果是响应消息，则根据服务码以及注册列表将消息返回给相应的订阅者；数据回返时根据注册列表中的过滤条件选择回返方式，回返方式可自定义。如果是取消订阅消息，则将该订阅者从注册列表中删除，当注册列表为空时，数据转发服务将向该类型的消息服务提供方发送取消订阅消息。如果是探测消息，则提示服务提供方正常运行，并根据业务需求进行相关处理。

数据转发服务包含服务探测机制，当某个类型的请求超过某个阀值未收到响应时，消息服务分发构件将自动向服务端发送该类型的订阅请求。超时阀值可根据不同的服务需求进行独立设置。

数据转发服务类图如图2所示，主要类功能如下：

(a)CMsgDispatchMgr类：初始化运行环境，提供服务总接口；

(b)MsgParser类：消息解析，获取消息服务码等必要信息；

(c)CServiceModMgr类：服务模式管理类，提供服务标准接口；

(d)CServiceMod类：服务模式父类，定义服务模式统一接口；

(e)CMulProcessMgr类：多进程模式，转发模块由进程组成；

(f)CThreadMgr类：线程池管理类，管理转发线程

(g)CSerialize类：提供序列化与反序列化方法

(h)CMsgSubscribeMgr类：订阅请求注册及转发、响应消息分发以及其他各类型消息处理；

(i)CSubscribe类：定义订阅者注册信息格式，包括订阅者地址、过滤参数等必要信息

(j)CMsgReqSendFactory类：订阅请求信息发送方式管理

(k)CMsgReqSendFactory类：响应数据回返方式管理；

(3)转发任务同步

数据转发任务到达某一转发服务器后，该转发服务器获取该任务的哈希码，根据哈希码将该转发任务通过系统内部高速通道，将其转发到相应的处理服务器进行处理。集群内部各转发服务器之间通过socket长连接进行通信，保证转发服务器间的高速数据同步。当某一转发服务器崩溃时，触发系统内部的负载均衡算法，将崩溃转发服务器的转发任务重新分配给其他转发服务器，保证数据不丢失及服务的正常运行。

(4)序列化与反序列化

当转发服务器对服务存在内存使用限制时，需要采用序列化技术对内存任务队列进行优化。当内存中的数据量达到预设内存大小时，将后续接收到的消息进行序列化处理，序列化格式规定如下：

消息类型(1个字节)+报文头长度(2个字节)+报文头内容+数据块长度(4个字节)+数据块内容+文件名长度(2个字节)+文件名

当内存中的任务处理完毕后者达到某一规定的阈值后，将序列化文件中的消息反序列化入内存任务队列中进行处理。

(5)事务处理

分布式消息队列接收到事务类型转发任务后，如果事务中各子任务之间没有顺序要求，或者只存在局部顺序性要求，则事务将被拆分为多个小块任务进行处理，各小块任务可能经由其他转发服务器转发处理。各小块任务的处理结果最终汇集到初始接收任务转发服务器，由该服务器服务将各小块任务结果进行汇总，并最终反馈给事务请求提交者。

(6)消息顺序与消息优先级

相同优先级的数据转发任务按照转发服务器接收到的顺序进行转发，高优先级的任务根据优先等级顺序发送。某一订阅端(或发布端)发送到转发服务器的多个子任务，如果子任务之间存在顺序要求，则按照顺序进行转发，某一子任务失败，将导致整个任务的失败。多个订阅端(或者发布端)之间的任务顺序没有要求。任何一个小块任务的失败将导致整个任务的失败。

(7)数据持久化及生命周期

数据转发任务在转发失败后，分布式消息队列将失败任务进行本地持久化存储，并在其生命周期内进行尝试重发，发送成功或者生命周期结束后，将失效数据进行清理。

(二)分布式消息服务接口

分布式消息服务接口是Zookeeper集群节点的一部分，每个接口库作为Zookeeper集群的一个临时节点，接口库内部通过监视服务获取转发服务器地址信息及状态信息，用于用户选择所需的转发服务器。

分布式消息服务接口包括订阅端接口和发布端接口，订阅端接口用于提交订阅请求，包括事务处理请求等；发布端接口用于发布任务处理数据。

接口库中通过调用ZooKeeper相关接口(包括zoo_exists()、zoo_get_children()、zoo_get()、watcher()函数)获取转发服务器地址列表，并随机选择一个地址作为转发地址进行通信。

Claims (7)

1.一种分布式的消息转发方法，其特征在于以分布式管理工具Zookeeper实现各转发服务器间的配置同步以及状态管理，每个转发服务器都作为Zookeeper集群中的一个节点，每个转发服务器节点对其他转发服务器的状态进行监控，当其他转发服务器节点状态发生变化时，通过负载均衡算法，对发生变化的转发服务器任务进行重新分配；

并且，将分布式消息服务接口作为Zookeeper集群节点的一部分，每个接口库作为Zookeeper集群的一个临时节点，接口库内部通过监视服务获取转发服务器地址信息及状态信息，以选择所需的转发服务器；所述分布式消息服务接口包括订阅端接口和发布端接口，订阅端接口用于提交订阅请求；发布端接口用于发布任务处理数据。

2.根据权利要求1所述的分布式的消息转发方法，其特征在于：转发服务器数据转发服务具体实现流程为：

一、初始化运行环境，获取服务转发配置信息，包括服务类型、服务提供方地址、采用的通信方式以及服务自动探测周期，配置信息记录到服务转发表中；

二、数据转发服务接收消息；

三、数据转发服务对消息进行解析，获取消息哈希码，并根据哈希码转发到相应的处理服务器；

四、数据处理服务器对消息进行解析，获取消息类型以及消息服务码，并根据消息类型及服务码进行相应的处理。

3.根据权利要求2所述的分布式的消息转发方法，其特征在于当转发服务器对服务存在内存使用限制时，采用序列化技术对内存任务队列进行优化：当内存中的数据量达到预设内存大小时，将后续接收到的消息进行序列化处理；当内存中的任务处理完毕后者达到某一规定的阈值后，将序列化文件中的消息反序列化入内存任务队列中进行处理。

4.根据权利要求2所述的分布式的消息转发方法，其特征在于当接收到事务类型转发任务时，如果事务中各子任务之间没有顺序要求，或者只存在局部顺序性要求，则事务将被拆分为多个小块任务进行处理，各小块任务可能经由其他转发服务器转发处理；各小块任务的处理结果最终汇集到初始接收任务转发服务器，由该服务器服务将各小块任务结果进行汇总，并最终反馈给事务请求提交者。

5.根据权利要求2所述的分布式的消息转发方法，其特征在于：相同优先级的数据转发任务按照转发服务器接收到的顺序进行转发，高优先级的任务根据优先等级顺序发送。

6.根据权利要求2所述的分布式的消息转发方法，其特征在于：数据转发任务在转发失败后，分布式消息队列将失败任务进行本地持久化存储，并在其生命周期内进行尝试重发，发送成功或者生命周期结束后，再将失效数据进行清理。

7.根据权利要求2所述的分布式的消息转发方法，其特征在于，步骤四中所述基本消息类型包括：请求消息、响应消息、取消订阅消息以及探测消息；

如果接收到的消息类型是请求消息，并且注册列表中没有该类型的请求，或者请求参数不相同，则根据服务转发表将消息转发给相应的服务提供方，并将该订阅信息同步到MASTER服务器，MASTER触发各转发服务器之间的订阅同步功能，将订阅列表同步；另外，如果已有该类型的请求，但超过某个时间阀值未收到响应，数据转发服务将重发该订阅请求；

如果是响应消息，则根据服务码以及注册列表将消息返回给相应的订阅者；数据回返时根据注册列表中的过滤条件选择回返方式，回返方式可自定义；

如果是取消订阅消息，则将该订阅者从注册列表中删除，当注册列表为空时，数据转发服务将向该类型的消息服务提供方发送取消订阅消息；

如果是探测消息，则提示服务提供方正常运行，并根据业务需求进行相关处理。