一种面向消息的数据分发中间件系统的制作方法

1.本发明涉及数据分发领域，更具体涉及一种面向消息的数据分发中间件系统。


背景技术：

2.中间件是在网络环境下一种起承上启下作用的基础软件。其主要作用是管理各种网络资源，为网络应用软件提供有效的开发、部署和运行平台，它所对应的解空间更靠近网络应用所面临的问题空间，因而可视为支持快速构建网络应用的基础软件。中间件通常是由一个api定义的软件层，它负责处理不兼容的操作系统或文件结构，调节客户机与服务器或服务器与服务器之间的通信，通常工作在网络层或传输层之上并且和下层的通信服务相互独立。其工作机制为:客户端的应用程序需要从网络中的某个地方获取一定的数据或服务，这些数据或服务可能处于一个运行着不同操作系统和特定查询语言数据库的服务器中。客户机/服务器应用程序负责寻找数据的部分只需访问一个中间件系统，由中间件完成到网络中找到数据或服务，进而传输客户请求，重组答复信息，最后将结果送回应用程序的任务。
3.面向消息的中间件(mom，message oriented middleware)是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可在分布环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。mom一般可以分为两种形式:消息传递(message passing)和消息队列(message queuing)。消息传递在建立大型的分布式应用中比较常见。其主要的模式是(publish-subscribe)方式。采用该方式，程序只需要简单地将消息以主题方式发送出去，由中间件来负责将消息传递给所有订购该主题的程序。mom主要通过agents技术来实现publish-subscribe方式应用。当程序广播消息时，首先与一个代理进行连接，将消息传递给代理。代理负责路由消息给相应的程序。由于代理可以实现消息的动态路由功能，因此，该方式能够提供较好的容错性能，但它缺乏mom的异步特性，不太适合长时间网络断开的情况。消息队列方式允许程序无需直接建立起连接即可发送和接收消息。程序只须简单地将消息发送给消息队列，由消息队列负责消息的传递，对应用程序完全透明。消息队列采用异步方式，为信息提供了一个安全的存储方式，特别适用于不是直接连接的应用，如移动用户、发送方或接收方进程可能处于不活动状态的应用。它的缺点是需要一些配置工作，性能不是很高，而且如果队列丢失，整个系统将受到影响，并且消息收发过程一旦消息量大容易造成拥塞从而导致转发速度过慢。
4.中国专利授权公告号cn104506496b，公开了基于oraclestreams技术的准实时数据增量分发中间件及方法，数据源模块，用于捕获操作信息生成捕获消息队列，并传递至应用消息队列，对应用消息队列中的消息进行解析，然后传输至tcp服务器上的消息接收与处理模块；消息接收与处理模块，用于接收tcp消息，将消息解析成服务器可识别的异步处理消息，根据设定转换清洗规则，对数据进一步进行处理后传送至数据潭模块；数据潭模块，用于接收处理后的数据更新，并将数据同步至多个异构的目标数据库。但是该发明中如果
队列丢失，整个系统将受到影响，并且消息收发过程一旦消息量大容易造成拥塞从而导致转发速度过慢。


技术实现要素：

5.本发明所要解决的技术问题在于现有技术数据分发中间件系统如果有队列丢失，整个系统将受到影响，并且消息收发过程一旦消息量大容易造成拥塞从而导致转发速度过慢。
6.本发明通过以下技术手段实现解决上述技术问题的：一种面向消息的数据分发中间件系统，包括核心管理模块、命令处理模块、线程管理器及消息处理模块，客户机上内置客户应用程序，服务器上内置监听程序，所述客户机分别与核心管理模块以及命令处理模块连接，核心管理模块分别与命令处理模块、线程管理器及消息处理模块连接，消息处理模块通过监听程序与服务器连接；
7.客户机以线程的形式发送的请求消息存储在命令处理模块的消息队列中，线程管理器开启线程池，供各种用户应用线程使用；核心管理模块从命令处理模块中的消息队列中取消息送到消息处理模块，消息处理模块有多个，根据消息队列中消息的数量选择开启消息处理模块的数量，监听程序中msgsrvaccess()函数将消息处理模块发送过来的消息打标签并通知服务器有分配过来的消息，服务器根据消息中的请求内容反馈回复信息给监听程序，监听程序通过消息处理模块将回复信息发送到客户应用程序。
8.本发明客户机以线程的形式发送的请求消息存储在命令处理模块的消息队列中，根据消息队列中消息的数量选择开启消息处理模块的数量，如果有队列丢失，没有丢失队列的消息处理模块继续运行，丢失队列的消息处理模块也能基于上述过程继续向命令处理模块中的消息队列中取消息，整个系统不会受到影响，并且整个过程中多个消息处理模块参与，实现多线程的消息转发，在消息量大的情况下，多个消息处理模块各自分担部分消息量，不会造成拥塞，大大提升消息转发速度。
9.进一步地，所述消息处理模块接收到消息以后，对消息的处理过程为：
10.步骤a：读取消息头中对消息总长的描述符n；
11.步骤b：将总长n的消息分为m段，每段消息的长度为n/m；
12.步骤c：消息处理模块向其p个cpu内核发起请求，请求cpu中断处理；
13.步骤d：将m段消息放入m个队列中，并设置结束读取的标志位flag；
14.步骤e：p个cpu读取m个队列，如果p≥m，则m个队列同时读完，标志位flag置位1；
15.步骤f：如果p《m，则先读取前p个队列，再依次读取m-p个队列，直到所有队列读取完成，标志位flag置位1。
16.进一步地，所述打标签的消息与服务器的配置文件中记载的服务器名、ip、队列和端口相对应，端口和设备的信息对应，打标签的消息发送给服务器以后根据对应的端口取得设备的信息。
17.更进一步地，基于sax模型解析xml文件的方式读取所述配置文件。
18.更进一步地，读取所述配置文件的过程为：
19.事件触发，判断节点类型；
20.如果是节点开始，创建队列，如果不是节点开始，释放队列内存空间；
21.如果是req或者res节点，获取兄弟节点个数，如果不是req或者res节点，释放队列内存空间；
22.获取兄弟节点个数之后判断是否为select或者option节点，如果是select或者option节点则重新进入节点开始，并且深度加1后，创建一个新的队列，如果不是select或者option节点则结束解析过程；其中，req为请求节点，res为回复节点，select为选择节点，option也为选择节点。
23.更进一步地，所述消息的收发过程为：
24.读取配置文件；
25.根据配置文件的参数连接相应的服务器；
26.判断消息管理器是否停顿，如果是，则等待一个时间周期后继续判断是否停顿，如果不是，则判断是否有待服务器接收的消息，如果有则取消息并解析后放入接收缓冲区，如果没有则判断接收缓冲区是否为空，如果是空则结束线程，如果不为空则取消息并且分类以后重新封装消息；
27.服务器接收到封装消息以后根据消息的请求内容提取请求内容对应的回复信息发送到客户应用程序；
28.客户应用程序判断是否有返回数据，如果有则将其接收到返回数据的消息进行消息封装以后放入发送缓冲区，如果没有则判断是否等待超时，如果是，则产生超时消息并放入发送缓冲区，如果不是等待超时则返回上述是否有返回数据的步骤。
29.进一步地，还包括时间处理模块，所述核心管理模块与时间处理模块连接。
30.更进一步地，所述时间处理模块给客户机发送过来的每个请求消息打上截止时间戳，服务器进行回复消息的时候，如果回复消息的时间不早于这个截止时间就判定系统出现错误并将错误报告给核心管理模块。
31.本发明的优点在于：
32.(1)本发明客户机以线程的形式发送的请求消息存储在命令处理模块的消息队列中，根据消息队列中消息的数量选择开启消息处理模块的数量，如果有队列丢失，没有丢失队列的消息处理模块继续运行，丢失队列的消息处理模块也能基于上述过程继续向命令处理模块中的消息队列中取消息，整个系统不会受到影响，并且整个过程中多个消息处理模块参与，实现多线程的消息转发，在消息量大的情况下，多个消息处理模块各自分担部分消息量，不会造成拥塞，大大提升消息转发速度。
33.(2)本发明消息处理方法将消息分成m段由多个内核分别进行处理，大大提升消息处理速度，进一步避免系统拥塞。
34.(3)本发明建立消息处理模块发送过来的任务消息和服务器的配置文件中的特定服务器名、ip、队列和端口相对应的快速映射关系，缩短消息转发速度。
35.(4)客户机由于报文数目多，报文信息量大，与之对应的服务器的配置文件较大，现有技术基于dom的解析方式读取此配置文件速度会比较慢，本发明基于sax模型解析配置文件，过程简单，解析速度快。
附图说明
36.图1为本发明实施例所公开的一种面向消息的数据分发中间件系统的架构示意
图；
37.图2为本发明实施例所公开的一种面向消息的数据分发中间件系统中核心管理模块初始化其他模块的示意图；
38.图3为本发明实施例所公开的一种面向消息的数据分发中间件系统的的逻辑状态示意图；
39.图4为本发明实施例所公开的一种面向消息的数据分发中间件系统中消息处理模块获取客户机请求的消息对应的消息内容的过程示意图；
40.图5为本发明实施例所公开的一种面向消息的数据分发中间件系统中解析配置文件的过程示意图；
41.图6为本发明实施例所公开的一种面向消息的数据分发中间件系统中消息收发过程示意图。
具体实施方式
42.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
43.如图1所示，一种面向消息的数据分发中间件系统，包括核心管理模块1、命令处理模块2、线程管理器3、时间处理模块4及消息处理模块5，客户机6上内置客户应用程序7，服务器8上内置监听程序9，所述客户机6分别与核心管理模块1以及命令处理模块2连接，核心管理模块1分别与命令处理模块2、线程管理器3、时间处理模块4及消息处理模块5连接，消息处理模块5通过监听程序9与服务器8连接。以下介绍个模块的主要作用。
44.核心管理模块1的核心管理类(controller)初始化其他四个子模块如图2所示，当核心管理模块1启动时，它会初始化其他四个子模块，开启它们的线程。核心管理模块1首先负责开启其他四个模块，用户命令由命令处理类(commandprocessor)的监听线程从客户机6通过网络获得。然后将消息转发到消息处理类(msgprocessor)，由它统一管理。时间处理类(timeprocesser)在这里起着控制流程先后的作用。系统启动后由controller类的main()函数进入，首先会检查参数是否正确，如果参数错误则中止，如果正确就创建配置实例，接着初始化配置。配置文件在根目录下为config.xml，其中包含着网络设备的服务器8地址、端口等消息。执行过程中，程序还会开启3个线程，分别创建执行日志、调试日志和客户端启动日志。一切工作准备就绪后，就创建controller线程。这个线程继承自threephaserunnable类，而它又继承自runnable的子类baserunnable，baserunnable里定义了很多变量，携带着系统最重要的一些状态信息，如消息队列queue，任务状态curstate等等。controller类run()方法开启以上四个模块的线程。在每个继承自threephaserunnable类的子类中都有一个while语句，不停的从消息队列中取消息。
45.消息处理模块5负责接收并处理核心管理模块1分派过来的消息。它启动的时候，根据消息量开启一定数量的msgcontroller子线程即线程池。它们空闲着等待消息的到来，当有一个消息任务来的时候，便开启其中的一个线程负责处理。这个类调用了msg.listener类的监听函数，通过msgsrvaccess()来实现与服务器8的信息交换，它通过
eventbodyaccessresult提供的数据信息来寻找目标服务器8和端口号，以及队列号。具体信息：、
46.server:服务器8名。
47.messageresult:通讯是否异常。
48.message:来自用户的消息。
49.listenerid:设备标识号。
50.msgsrvaccess()方法与服务器8通讯依靠的是jms api。它的方便简洁给开发带来了极大的便利，同时它也具有跨平台性，不受硬件和操作系统的限制。在设备信息以消息的形式通过msgsrvaccess()方法从目标服务器8上取回来时，会返送到msgcontroller类，然后交给msgprocessor，接着送到核心管理模块1。核心管理模块1会将消息命令转给命令处理模块2commandprocessor，由它来处理。
51.命令处理类(commandprocessor)负责沟通用户程序(commandclient)，它运行时会开启子线程commandlistener,commandlistener使用socket类提供的接口函数实现通讯。用socket进行客户/服务器8之间的通信编程。socket是两个实体之间进行通信的有效端点。通过socket可以获得源ip地址和源端口、终点ip地址和终点端口。通过socket客户/服务器8编程可以创建一个能被许多人使用的分布式程序，并且所有客户均可以用统一的前端进行工作，并与服务器8进行通信。图2中threadmanager为线程管理器3的线程管理类。
52.整个系统的状态有七种：exec,init,start,idle,end,term,exit。模块开启、运行、关闭的逻辑状态如图3所示。其中前三种是系统启动时所要经历的状态，在各个状态五个模块分别执行自己本状态的启动指令，将这五个模块的基类定名为threephaserunnable。在exec状态时，系统会启动好所有的主要模块；在init状态时，所有模块都根据配置信息设置好自己的参数；在start模块时，系统建立与服务器8的连接；idle状态就是系统运行的状态，循环和服务器8进行通信。end,term,exit是关闭阶段的状态，分别对应着前面的三个状态。以下详细介绍本发明的系统的工作过程：
53.根据用户命令从服务器8上取消息，发送到客户应用程序7，处理完成后将结果返回给用户。系统两端分别为用户命令发送端和服务器8端，中间用消息中间件联系起来。发送方和接收方都拥有自己的主函数、监听端口和一系列可操作的事件。客户机6以线程的形式发送的请求消息存储在命令处理模块2的消息队列中，线程管理器3开启线程池，供各种用户应用线程使用；核心管理模块1从命令处理模块2中的消息队列中取消息送到消息处理模块5，消息处理模块5有多个，根据消息队列中消息的数量选择开启消息处理模块5的数量，监听程序9中msgsrvaccess()函数将消息处理模块5发送过来的消息打标签并通知服务器8有分配过来的消息，所述打标签的消息与服务器8的配置文件中记载的服务器8名、ip、队列和端口相对应，端口和设备的信息对应，打标签的消息发送给服务器8以后根据对应的端口取得设备的信息。服务器8根据消息中的请求内容反馈回复信息给监听程序9，监听程序9通过消息处理模块5将回复信息发送到客户应用程序7。消息处理模块5获取客户机6请求的消息对应的消息内容的过程如图4所示。所述时间处理模块4给客户机6发送过来的每个请求消息打上截止时间戳，服务器8进行回复消息的时候，如果回复消息的时间不早于这个截止时间就判定系统出现错误并将错误报告给核心管理模块1。
54.所述消息处理模块5接收到消息以后，对消息的处理过程为：
55.步骤a：读取消息头中对消息总长的描述符n；
56.步骤b：将总长n的消息分为m段，每段消息的长度为n/m；
57.步骤c：消息处理模块5向其p个cpu内核发起请求，请求cpu中断处理；
58.步骤d：将m段消息放入m个队列中，并设置结束读取的标志位flag；
59.步骤e：p个cpu读取m个队列，如果p≥m，则m个队列同时读完，标志位flag置位1；
60.步骤f：如果p《m，则先读取前p个队列，再依次读取m-p个队列，直到所有队列读取完成，标志位flag置位1。
61.如图5所示，基于sax模型解析xml文件的方式读取所述配置文件。采用sax解析模式实现处理所有到来的事件的事件处理程序。需要在应用程序代码中维护这个事件状态。需要跟踪解析器处在文档层次的哪个位置。sax处理涉及以下步骤：
62.(1)创建一个事件处理程序。
63.(2)创建sax解析器。
64.(3)向解析器分配事件处理程序。
65.(4)解析文档，同时向事件处理程序发送每个事件。
66.解析文档的过程为：
67.事件触发，判断节点类型；
68.如果是节点开始，创建队列，如果不是节点开始，释放队列内存空间；
69.如果是req或者res节点，获取兄弟节点个数，如果不是req或者res节点，释放队列内存空间；
70.获取兄弟节点个数之后判断是否为select或者option节点，如果是select或者option节点则重新进入节点开始，并且深度加1后，创建一个新的队列，如果不是select或者option节点则结束解析过程；其中，req为请求节点，res为回复节点，select为选择节点，option也为选择节点。
71.消息中间件负责服务器8与客户机6之间消息的传递，当服务器8上有要发送到客户机6的消息时，消息中间件从接收缓冲区中读出消息，同时该消息从队列中被删除。当业务逻辑组件对请求消息给予响应并生成处理结果即返回数据。本发明采用基于队列的消息传递机制。如图6所示，所述消息的收发过程为：
72.读取配置文件；
73.根据配置文件的参数连接相应的服务器8；
74.判断消息管理器是否停顿，如果是，则等待一个时间周期后继续判断是否停顿，如果不是，则判断是否有待服务器8接收的消息，如果有则取消息并解析后放入接收缓冲区，如果没有则判断接收缓冲区是否为空，如果是空则结束线程，如果不为空则取消息并且分类以后重新封装消息；
75.服务器8接收到封装消息以后根据消息的请求内容提取请求内容对应的回复信息发送到客户应用程序7；
76.客户应用程序7判断是否有返回数据，如果有则将其接收到返回数据的消息进行消息封装以后放入发送缓冲区，如果没有则判断是否等待超时，如果是，则产生超时消息并放入发送缓冲区，如果不是等待超时则返回上述是否有返回数据的步骤。
77.通过以上技术方案，本发明客户机6以线程的形式发送的请求消息存储在命令处
理模块2的消息队列中，根据消息队列中消息的数量选择开启消息处理模块5的数量，如果有队列丢失，没有丢失队列的消息处理模块5继续运行，丢失队列的消息处理模块5也能基于上述过程继续向命令处理模块2中的消息队列中取消息，整个系统不会受到影响，并且整个过程中多个消息处理模块5参与，实现多线程的消息转发，在消息量大的情况下，多个消息处理模块5各自分担部分消息量，不会造成拥塞，大大提升消息转发速度。
78.以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。