H.E.'s Blog

Story

最近项目中一直在使用GlassFish作为应用服务器,使用到 GlassFish中JMS/MDB(消息驱动Bean)的部分，项目对JMS服务的要求比较高不仅仅需要在单台服务器上运行，还需要在集群环境运行JMS服务。

查阅大量资料，网上N多讲的都是Jboss的JMS集群，很少有简述GlassFish集群JMS的，无意找到了一篇印度阿三的写的文章,经过反复推敲，证明这样的实施方案虽然是SUN公司比较推崇的，实施起来成本比较大，将来需要投入的维护成本也不小。印度阿三提出的做法给人感觉：要吃块牛肉而已，现在牵头牛过来给我了。请看原文 。

将此方法放弃，直接使用OpenMQ JMS服务，OpenMQ也是SUN的产品，只不过现在和GlassFish整合包含在GlassFish里面，也可以独立使用。

在项目测试环境中运行了OpenMQ 的集群，没有用GlassFish里面提供的MDB解决方案，欢快的使用着OpenMQ JMS 集群功能，2台机器上的JMS 队列也在欢快的 进行消息同步。

 不久后问题来了。。。。。
 
OpenMQ和我们自己写的客户端程序建立的是socket 连接，也就是说服务端OpenMQ JMS服务一旦down掉，那么JMS客户端程序就跟白痴一样还在等待接收消息，却不知道OpenMQ JMS服务端已经down掉了。系统中没有体验到失效转发。

项目组的一位仁兄 写了一个程序 通过轮询检测 我们自己写的JMS客户端程序 是否抛出异常判定 OpenMQ JMS服务端是否还活着。

嗯，这位仁兄的方法果然有效 原先我们自己写的客户度程序不是呆子了，智能了一些，知道服务端down掉以后该做什么。

这样的方法虽然达到了效果，但是比较简陋，性能上有种说不出的痛。不知道将来会出现什么问题，还是需要依靠自己去解决，会有一定程度的风险。

How

接下来的几天，我google到一份讲述 J2EE服务器原理的书籍，通过理论上的知识让我知道，通过J2EE容器发送JMS消息，跟写通过容器中JNDI整合JDBC方式向数据库做操作一样。首先要查找数据源，建立数据库连接。JMS程序也是一样。可以通过API调用JMS服务器直接操作，也可以通过容器JDNI的方式操作。和JDBC的区别就是分为 发送着/接受者(Queue)，发送者/订阅者(Topic)。

那么换个思维方式，也就是说在GlassFish中配置一个JNDI作为一个别名，实际服务器的目标地址可以配置成本地/远程 JMS服务器，可以是一个也可以是多个服务器。很多事情就可以交给GlassFish容器帮我们去做了，比如：超时重连，切换失效主机，事务等。这样可以对项目进行重新架构，详见下图：

查看大图请点击这里

说明：
        1.客户端收/发程序–>部署在容器中–>容器JNDI—>JMS Server—>Message Queue—>Message 。
        2.发送者向JMS服务器中的消息队列发送100个消息 ，通过JMS集群 接收端如果有2台服务器每台服务器会接收50个，有4台每台接收25个，以此类推，这样达到了压力分载的效果。
        3.无论在发送端还是在接收端任意一台服务器Down掉，JMS集群服务器会自动分配负载。

拓展话题：1.JMS与EJB中MDB的关系到底是什么？ 2.SUN公司推出的JMS1.0 和JMS1.1在功能上、标准上有什么区别？
口水：“没有100%最佳的实践方案，往往最佳实践就是最折中的一种方法。”
 
参考资料：http://www.novell.com/documentation/extend52/Docs/help/MP/jms/admin/clustering.html
参考资料：http://www.wnetw.net/jclub/technology/read.jsp?itemid=762
参考资料：http://today.java.net/article/2008/01/18/jms-messaging-using-glassfish
参考资料：http://developers.sun.com.cn/Java/jms-messaging-using-glassfish.html

相关文章
大型系统中使用JMS优化技巧–Sun OpenMQ
GlassFish 优化技巧 -GlassFish HTTP/1.1 GZIP
Glassfish(EJB) 与Quartz Job Scheduler整合
GlassFish 文档
GlassFish 数据库连接池的配置步骤(图解)
–end–