基于CORBA的JAVA消息服务中间件的设计与优化

基于CORBA的JAVA消息服务中间件的设计与优化

摘要

CROBA、DCOM等RPC中间件在大规模的分布计算应用中有其局限性。而Java消息服务在异步通信、松散耦合和多对多通信等方面提供了强有力的支持。本文介绍了CJMQ－一个基于CORBA的多线程Java消息服务中间件，描述了CJMQ的体系结构，讨论了消息派发机制的优化设计，并且对当前CJMQ的实现进行了性能评价和分析。关键字Java消息服务；消息中间件；CORBA中图分类号TP393文献标识码A当前，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进行了性能分析与评价。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）语义，即消息可以丢失但是不能发送两次。如图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，该参数可以由管理员配置。系统初始化时生成一定数目的派发线程，由调度器调度这些线程发送消息队列中的消息，如果仍有新的消息到来而线程数不够时，则系统生成新的线程处理消息直到达到设定的MaxThreadNum值。这样可以重用线程池中的线程，避免了前两种策略的缺点。Connectionmanager接受客户的建立连接的请求，并分配该连接一个唯一的连接标识。客户在请求连接的时候，会同时发送自己的消息处理对象（messagehandlerobject）的引用；Connectionmanager将此对象引用和连接标识存储到派发缓冲和数据库中。Leasemanager主要有两个功能，其一是检测所有已建立连接的客户是否还联通，如果已经断开则清除该客户的连接信息；并且如果该客户没有持久订阅，还将清除发送给它的消息以及应答；其二是检测消息队列中的消息是否已经过期，如果过期则清除该消息。单位时间内的消息吞吐量是衡量MOM系统性能的一个重要指标，而消息派发机制对该性能影响很大。这一节主要阐述我们在设计CJMQ时对其消息派发机制的优化。问题：在点对点模型中，多个派发线程会同时访问派发缓冲（存放客户连接标识和其消息处理对象的引用）以便将消息分别派发给某个接收者。同时新建连接或者关闭连接也会导致对派发缓冲的更改（增加或者删除）。为了同步，传统的做法是采用锁机制，当第一个线程访问缓冲时，首先对该缓冲加锁，然后再对缓冲中的数据进行处理，处理完毕后解锁，以便使其他线程可以访问该缓冲。如果缓冲加锁，则任何其他线程都必须等待，直到解锁为止。在CJMQ的实现中如果采用锁机制，会导致派发线程访问的串行，严重影响系统性能。优化：用读/写锁同步多线程对派发缓冲的访问。考虑到在点对点模型中派发操作主要是读取派发缓冲中的消息处理对象引用，然后调用它的发送消息接口，而并不更改（增加和删除）派发缓冲。对于这一类操作，可以使用读锁；对于更改派发缓冲的操作，可以使用写锁。读锁可以并发，而写锁必须与其它写锁和读锁互斥。结果：使多个派发线程可以并发访问派发缓冲，从而大大提高了系统的消息吞吐率。但是对于派发缓冲的更改，还必须串行。问题：在发布/订阅模型中，每个派发线程通过使用叠代器（iterator）循环调用派发缓冲中每个接收者的消息处理对象接口实现广播派发，这要求在循环过程中不能对派发缓冲更改。但是新建连接或者关闭连接会导致对派发缓冲的更改（增加或者删除）。在这种情况下，如果采用传统的锁机制，会限制派发线程的并发；如果采用上一节的读/写锁机制，尽管允许派发线程的并发，但是可能又会造成更改线程的“饥饿”，导致新的接收者不能及时接收消息或者使派发线程调用废弃的消息处理对象接口而浪费系统资源。优化：采用先拷贝、再发送的算法。派发线程首先给派发缓冲加锁，然后把消息的所有接收者的消息处理对象引用拷贝到一个临时的缓冲区，再释放锁以允许其它线程尽快进入。这时通过对临时缓冲区中的对象接口循环调用，实现广播派发消息。结果：尽管广播派发耗时较长，但是由于派发线程没有独占派发缓冲（拷贝的耗时很少），从而最大可能的提高了派发线程的并发性。此外，又不会使更改线程处于“饥饿”状态，它依然可以更改派发缓冲。l测试环境所有测试都基于以下软硬件配置：两台IntelPIII500MHZ，128MRAM；操作系统Windows2000，Java编译器及虚拟机为SUNJDK1.3，CORBA产品为VisiBroker4.0；局域网为100Mbit/s以太网。l测试方法影响MOM系统消息吞吐量的主要因素有：（1）消息是否为持久消息；（2）消息体的大小；（3）发布者和接收者的数量；（4）发布者、消息服务、接收者各自所处的位置。消息吞吐率的获得是让一个消息发布者连续的发送消息（测试中发送500个消息），由一个或者若干个接收者接收消息，然后报告单位时间内收到的消息数，以其作为消息吞吐量。l测试结果表1显示了CJMQ单位时间内的消息吞吐量。从表中可以看出：表1CJMQ消息吞吐量①持久消息的吞吐量比非持久消息的吞吐量低。这是因为CJMQ对持久消息要做更多的处理，它要把持久消息存入数据库中。非持久消息更有效率，但是持久消息提供了可靠性保证，因此在选择消息类型时要在效率和可靠性之间做出权衡。②消息的大小也影响吞吐量。消息越小，效率越高。③表中显示接收者、发送者和CJMQ分布在局域网的吞吐量比在同一台计算机要高。原因是当三者在一台计算机时，它们要共享CPU和内存资源，导致性能降低；而分布在局域网中时不会竞争这些资源。④比较一个接收者和五个接收者的吞吐量。理论推测后者可能是前者的五分之一，但是事实是后者大约是前者的三分之一。这说明我们设计的多线程派发策略取得了很好的效果，系统性能得到了较大的提升。JAVA消息服务为企业系统集成、电子商务等各种大规模分布式应用提供了强大的支持，同时也为各种不同MOM产品的互操作提供了统一的框架。本文描述了CJMQ－一个基于CORBA的多线程高性能Java消息服务中间件，包括其体系结构和对消息派发机制的优化以及对其性能的评测。对于JMS的事务和消息过滤机制的研究是我们下一阶段的主要目标。参考文献[1]SunMicrosystems，Inc.，MountainViewCA，U.S.A.JavaMessageService，Nov.1999.[2]ObjectManagementGroup，TheCommonObjectRequestBroker:ArchitectureandSpecification，2.4ed.，Oct.2000.[3]G.Banavar，T.Chandra，R.Strom，D.Sturman，“ACaseforMessageOrientedMiddleware”，LectureNotesinComputerScience，Vol0，Num1693，pp