Connection manager接受客户的建立连接的请求,并分配该连接一个唯一的连接标识。客户在请求连接的时候,会同时发送自己的消息处理对象(message handler object)的引用;Connection manager将此对象引用和连接标识存储到派发缓冲和数据库中。
Lease manager主要有两个功能,其一是检测所有已建立连接的客户是否还联通,如果已经断开则清除该客户的连接信息;并且如果该客户没有持久订阅,还将清除发送给它的消息以及应答;其二是检测消息队列中的消息是否已经过期,如果过期则清除该消息。

4 CJMQ消息派发机制的优化
单位时间内的消息吞吐量是衡量MOM系统性能的一个重要指标,而消息派发机制对该性能影响很大。这一节主要阐述我们在设计CJMQ时对其消息派发机制的优化。
4.1派发消息给一个接收者问题:在点对点模型中,多个派发线程会同时访问派发缓冲(存放客户连接标识和其消息处理对象的引用)以便将消息分别派发给某个接收者。同时新建连接或者关闭连接也会导致对派发缓冲的更改(增加或者删除)。为了同步,传统的做法是采用锁机制,当第一个线程访问缓冲时,首先对该缓冲加锁,然后再对缓冲中的数据进行处理,处理完毕后解锁,以便使其他线程可以访问该缓冲。如果缓冲加锁,则任何其他线程都必须等待,直到解锁为止。在CJMQ的实现中如果采用锁机制,会导致派发线程访问的串行,严重影响系统性能。
优化:用读/写锁同步多线程对派发缓冲的访问。考虑到在点对点模型中派发操作主要是读取派发缓冲中的消息处理对象引用,然后调用它的发送消息接口,而并不更改(增加和删除)派发缓冲。对于这一类操作,可以使用读锁;对于更改派发缓冲的操作,可以使用写锁。读锁可以并发,而写锁必须与其它写锁和读锁互斥。
结果:使多个派发线程可以并发访问派发缓冲,从而大大提高了系统的消息吞吐率。但是对于派发缓冲的更改,还必须串行。
4.2派发消息给多个接收者问题:在发布/订阅模型中,每个派发线程通过使用叠代器(iterator)循环调用派发缓冲中每个接收者的消息处理对象接口实现广播派发,这要求在循环过程中不能对派发缓冲更改。但是新建连接或者关闭连接会导致对派发缓冲的更改(增加或者删除)。在这种情况下,如果采用传统的锁机制,会限制派发线程的并发;如果采用上一节的读/写锁机制,尽管允许派发线程的并发,但是可能又会造成更改线程的“饥饿”,导致新的接收者不能及时接收消息或者使派发线程调用废弃的消息处理对象接口而浪费系统资源。
优化:采用先拷贝、再发送的算法。派发线程首先给派发缓冲加锁,然后把消息的所有接收者的消息处理对象引用拷贝到一个临时的缓冲区,再释放锁以允许其它线程尽快进入。这时通过对临时缓冲区中的对象接口循环调用,实现广播派发消息。
结果:尽管广播派发耗时较长,但是由于派发线程没有独占派发缓冲(拷贝的耗时很少),从而最大可能的提高了派发线程的并发性。此外,又不会使更改线程处于“饥饿”状态,它依然可以更改派发缓冲。
5 CJMQ性能测试
l 测试环境
所有测试都基于以下软硬件配置:两台Intel PIII 500MHZ,
l 测试方法
影响MOM系统消息吞吐量的主要因素有:(1)消息是否为持久消息;(2)消息体的大小;(3)发布者和接收者的数量;(4)发布者、消息服务、接收者各自所处的位置。
消息吞吐率的获得是让一个消息发布者连续的发送消息(测试中发送500个消息),由一个或者若干个接收者接收消息,然后报告单位时间内收到的消息数,以其作为消息吞吐量。
l 测试结果
表1显示了CJMQ单位时间内的消息吞吐量。从表中可以看出:
|
消息类型大小 测试条件 |
非持久消息(个/秒) |
持久消息(个/秒) | ||
|
1024 byte |
128 byte |
1024 byte |
128 byte | |
|
一个发送者、一个接收者和CJMQ在同一台计算机 |
65 |
70 |
56 |
64 |
|
一个发送者和接收者在一台计算机,CJMQ在局域网中的另一台计算机 |
101 |
143 |
90 |
127 |
|
一个发送者和五个接收者在一台计算机,CJMQ在局域网中的另一台计算机 |
32 |
53 |
22 |
48 |
表1 CJMQ消息吞吐量
① 持久消息的吞吐量比非持久消息的吞吐量低。这是因为CJMQ对持久消息要做更多的处理,它要把持久消息存入数据库中。非持久消息更有效率,但是持久消息提供了可靠性保证,因此在选择消息类型时要在效率和可靠性之间做出权衡。
② 消息的大小也影响吞吐量。消息越小,效率越高。
③ 表中显示接收者、发送者和CJMQ分布在局域网的吞吐量比在同一台计算机要高。原因是当三者在一台计算机时,它们要共享CPU和内存资源,导致性能降低;而分布在局域网中时不会竞争这些资源。
④ 比较一个接收者和五个接收者的吞吐量。理论推测后者可能是前者的五分之一,但是事实是后者大约是前者的三分之一。这说明我们设计的多线程派发策略取得了很好的效果,系统性能得到了较大的提升。
6 总结
JAVA消息服务为企业系统集成、电子商务等各种大规模分布式应用提供了强大的支持,同时也为各种不同MOM产品的互操作提供了统一的框架。本文描述了CJMQ-一个基于CORBA的多线程高性能Java消息服务中间件,包括其体系结构和对消息派发机制的优化以及对其性能的评测。对于JMS的事务和消息过滤机制的研究是我们下一阶段的主要目标。
参考文献
[1] Sun Microsystems, Inc.,
[2] Object Management Group, The Common Object Request Broker: Architecture and Specification, 2.4 ed., Oct. 2000.
[3] G. Banavar, T. Chandra, R. Strom, D. Sturman, “A Case for Message Oriented Middleware”, Lecture Notes in Computer Science, Vol 0, Num 1693, pp1-18, September 1999.
[4] Object Management Group, Notification Service Specification, OMG Document telecom/
[5] A. B. Arulanthu, C. O’Ryan, D. C. Schmidt, M. Kircher, and J. Parsons,“The Design and Performance of a Scalable ORB Architecture for CORBA Asynchronous Messaging,” in Proceedings of the Middleware 2000 Conference, ACM/IFIP, Apr. 2000.
[6] C.O’Ryan, D.C.Schmidt, and D.Levine , “Applying a Scalable CORBA Event Service to Large-scale Distributed Interactive Simulations,” in Proceedings of the 5th Workshop on Object-oriented Real-time Dependable Systems,IEEE,1999.11