java消息服务中间件设计_基于corba的java消息服务中间件的设计与优化.doc

基于corba的java消息服务中间件的设计与优化.doc

基于CORBA的JAVA消息服务中间件的设计与优化来源：bet365摘要CROBA、DCOM等RPC中间件在大规模的分布计算应用中有其局限性。而Java消息服务在异步通信、松散耦合和多对多通信等方面提供了强有力的支持。本文介绍了CJMQ－一个基于CORBA的多线程Java消息服务中间件，描述了CJMQ的体系结构，讨论了消息派发机制的优化设计，并且对当前CJMQ的实现进行了性能评价和分析。关键字Java消息服务；消息中间件；CORBA中图分类号TP393文献标识码A1引言当前，CORBA、DCOM、RMI等RPC中间件技术已广泛应用于各个领域。但是面对规模和复杂度都越来越高的分布式系统，这些技术也显示出其局限性：(1)同步通信：客户发出调用后，必须等待服务对象完成处理并返回结果后才能继续执行；(2)客户和服务对象的生命周期紧密耦合：客户进程和服务对象进程都必须正常运行；如果由于服务对象崩溃或者网络故障导致客户的请求不可达，客户会接收到异常；(3)点对点通信：客户的一次调用只发送给某个单独的目标对象。面向消息的中间件(MessageOrientedMiddleware，MOM)较好的解决了以上问题。发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中，在合适的时候再将消息转发给接收者。这种模式下，发送和接收是异步的，发送者无需等待；二者的生命周期未必相同：发送消息的时候接收者不一定运行，接收消息的时候发送者也不一定运行；一对多通信：对于一个消息可以有多个接收者。已有的MOM系统包括IBM的MQSeries、Microsoft的MSMQ和BEA的MessageQ等。由于没有一个通用的标准，这些系统很难实现互操作和无缝连接。JavaMessageService(JMS)是SUN提出的旨在统一各种MOM系统接口的规范，它包含点对点(PointtoPoint，PTP)和发布/订阅(Publish/Subscribe，pub/sub)两种消息模型，提供可靠消息传输、事务和消息过滤等机制。我们的工作是利用CORBA的开放、跨平台和跨语言的特性，以其作为底层通信机制，设计和实现一个开放、高性能的JMS中间件CJMQ。CJMQ支持点对点和发布/订阅两种消息模型，同时支持同步、异步通信机制，提供持久消息、优先级、可靠消息传输保证和持久订阅。本文首先简要介绍了JMS接口规范，然后详细描述了CJMQ的体系结构以及对消息派发机制的优化措施，最后对CJMQ进行了性能分析与评价。2JAVA消息服务JMS是SUN定义的一个纯接口规范而没有任何具体实现，它的标准API使应用程序可以不依赖某个具体的MOM系统。图1说明了JMS的主要概念。一个JMS应用由JMS消息服务、JMS客户、消息、目标(destination)和连接工厂(connectionfactory)两种管理对象所组成。JMS消息服务提供了两种消息模型：PTP模型和pub/sub模型，如图1所示。在PTP模型中，消息被发往特定的消息队列，然后由消息服务再发往接收者。PTP模型的特点是：(1)每个消息仅有一个接收者；(2)接收者成功处理消息后要发出应答。在pub/sub模型中，消息被发往基于某个主题(topic)的消息队列，而接收者必须先在它感兴趣的主题队列发出订阅请求，消息服务根据接收者的订阅情况来决定是否将消息发往接收者。这种模型的特点是：(1)每个消息也许有多个接收者；(2)接收者可以采取持久订阅机制。持久订阅指的是接收者要求收到所有发往某个Topic的消息即使该接收者没有和JMS服务器保持连接。服务器保留这些信息直到该接收者应答或者这些消息过期。JMS消息由三部分组成：消息头、属性和消息体。所有的消息都有相同的头部，包含了优先级、生存期、可靠性等QoS信息以及路由信息。服务器将依据这些信息对消息进行处理。属性是用户定义的名字值对(name-valuepairs)，可用来进行消息过滤和路由或者由应用程序自己进行处理。消息体包含要传送的具体消息，JMS定义了五类消息：Text、Map、Object、Stream、Bytes。JMS的传输模式分为持久模式(PERSISTENT)和非持久模式(NON-PERSISTENT)。持久模式指示JMS服务器要将消息保存在数据库中，以防止由于服务器崩溃造成的消息丢失。JMS规范要求持久性消息的传送要保证一次且仅有一次(once-and-only-once)语义，即消息既不能丢失也不能发送两次。非持久模式传送消息更有效率，因为不必将消息保存在数据库中。JMS规范要求非持久性消息的传送要保证至多一次(at-most-once)语义，即消息可以丢失但是不能发送两次。3CJMQ的系统结构3.1CJMQ的外部体系结构如图2所示，CJMQ提供了三种API以满足管理、Java应用和C＋＋应用的需要，它们的通信协议采用标准的CORBAIIOP协议以保证CJMQ的开放型以及和其他系统的互操作性。由于OMG会逐步扩展各种语言向CORBA的映射，因此CJMQ也会增加支持其他语言的客户端API。CJMQ有一个数据存储层，用以存储持久消息、系统配置参数、连接信息等数据，它可以通过JDBC访问SQLServer、Oracle、Sybase等关系数据库。3.2CJMQ的内部体系结构图3显示了CJMQ消息服务的内部主要结构。客户应用程序通过调用CJMQ提供的JMS函数库同CJMQ服务器通信。接收客户请求的是ORBAdaptor，它是一个通信层，在对接收的请求或者消息简单判断后，立即将该消息或者请求转发给适当的处理者。如果是发送者发送的消息，就将该消息放入到发送消息队列中；如果是接收者的应答消息，则将该消息放入到应答队列中；而如果是建立连接或者建立新的队列(queue)、主题(topic)的请求，则分别将请求转发给连接管理器(connectionmanager)和目标管理器(destinationmanager)。Messagequeue模块包含发送消息队列和应答消息队列以及持久消息管理器。由ORBadaptor转发的消息按类别分别进入这两个队列中。发送消息队列按照消息优先级排序，使最高优先级的消息排在最前面以尽快优先处理。同时，持久消息管理器根据消息头部持久属性的值来决定是否将消息存储在数据库中。如果是，则通过数据库连接池中的数据库连接将持久消息存储到数据库中。当CJMQ由于异常原因崩溃重新启动后，在初始化阶段会将持久消息读入消息队列中。采用何种线程策略向消息接收者发送消息对于系统的性能有着至关重要的影响。既可以采用一个客户一线程，也可以采用一个队列一线程或者采用线程池。一个客户一线程策略适用于客户数较少的情况，当客户数很多时，大量的线程会严重消耗系统资源，导致系统性能很差；一个队列一线程策略适用于消息较少的情况，当队列中消息数较多时，单线程来不及处理，导致系统传输消息的效率很低。我们的设计采用了线程池的策略。dispatcherthreadpool有一个线程数上限MaxThreadNum，该参数可以由管理员配置。系统初始化时生成一定数目的派发线程，由调度器调度这些线