JMS实践总结

from: http://www.blogjava.net/jjwwhmm/archive/2008/06/26/210840.html

by: Pony

 

1.消息类型的选择
Java的JMS消息类型有文本类型,对象类型,字节类型,流类型,XML类型,在实际项目中,用的最多的是文本类型,对象类型和xml类型的消息.建议 最好不用对象类型,因为如果用对象类型的话,调试的时候是很麻烦的,首先你必须要写专门的测试代码用来发送消息,第二,必须要管理对象所属的类的不同版 本,第三,不方便查看queue或者topic中的消息内容.而如果使用文本类型或者xml类型的消息,那么可以很容易的通过JMS中间件提供的一些管理 工具来发送测试消息,查看消息内容,并且更加容易管理不同版本之间的兼容性.如果一定要用对象类型消息的话,建议使用xstream把对象转化为xml

2.是使用queue还是topic?
这两者的定义是很清楚的,也很容易区分.但是在实际项目中,如何来取舍呢?我的建议是尽量用queue.如果你的项目用到了JMS,那么你的系统也应该是 到了需要部署在集群环境的规模了.用topic在集群环境下会带来很多麻烦.举个简单的例子,如果你是用MDB来处理topic的消息,你有一个MDB名 为SampleMDB,它以集群的方式分别部署在A服务器和B服务器上.那么有可能同一条topic消息被同一个MDB处理两次.虽然一些JMS中间件提 供商为解决这种问题提供了一些解决方案,例如把subsriber分组,但是它为开发和调试都带来了很大的麻烦.topic消息的处理也要比queue的 复杂,很难跟踪topic消息的处理过程.
那么,如果不用topic的话,怎么来实现topic这种性质的消息处理呢?可以写一个消息转发器,把一个queue上的消息转发给所有关注这个 queue的其它queue中.例如,有一个queue,名为SampleQ1,一个消息发送者sender,一个消息转发器router,有三个 handler A,B,C需要处理这个queue中的消息.那么,sender发送消息到SampleQ1,router接收SampleQ1的消息后分别发送到 SampleQ1_A,SampleQ1_B,SampleQ1_C,handler A,B,C分别从队列SampleQ1_A,SampleQ1_B,SampleQ1_C中接收消息.

3.用JMS来解决什么问题?
一提起JMS可以做什么,第一想到的就是异步处理.面试的时候问JMS可以做什么?大多数的回答是:用JMS来异步发送邮件!(到底应该怎么样构建一个邮 件发送系统不是本文的主题,以后有时间我会专门来谈谈在我的项目中,我是怎么来设计邮件发送系统的).其实,还可以用JMS来解决很多复杂的问题,例如分 布,并发,系统解耦,负载均衡,热部署,触发器等等,这些复杂的问题因为引入了JMS而变的更加简单.下面简单介绍下解决分布,并发问题的场景.
3.1 用JMS来解决并发问题
queue的概念大家都很清楚了,那就是queue里的一条消息只会被一个消息接收者处理.基于这个概念,我们可以在系统中对并发要求很严格的模块中引入 JMS的使用.例如,系统的送积分,一般这个模块是用一个定时器,例如quartz,每天定期查询数据库,如果发现有满足条件的记录,那么就把积分送给会 员.如果同时有多个quartz在运行,那么必须严格控制防止并发的对同一条记录送多次积分.解决这个问题有很多方法,可以通过业务的设计,系统的部署, 数据库的设计,事务的控制等方法来实现,在这里提一个用JMS来解决问题的方法:在插入记录的同时发送一个queue的消息.这样即使有多个送积分的 MDB实例在运行,也只会被一个实例处理.

3.2用JMS来解决分布的问题
解决分布有两种类型,第一种是指消息是集中的,但消息的处理是分布的.例如,系统可能会被分为前台与后台,这两个系统是部署在不同的网段里的.那么怎么把 前台发生的业务通知后台系统呢?当然,可以通过一个类似定时器的玩意定期去数据库查询.但这种方式要么就是浪费系统资源,可能在定期查询中80%的时间都 是在做无用功,要么就是业务请求没有被及时处理.,因为定期的时间总是有一个时间间隔的.用JMS来处理这个问题会怎么样呢?前台系统在处理完业务请求后 的同时发送一个消息到queue中,后台系统的消息接收者接收到消息后立即处理.这里消息的处理也可能有一定的延期,但这主要取决于消息服务器的硬件能 力,网络带宽,消息接收者的处理速度等.

第二中是指消息也是分布的.很多消息中间件都提供了消息路由的功能,即消息发送到一个消息服务器后,这个消息服务器根据定义的规则再把这条消息路由转发到 其它的消息服务器.例如,可能在北京的一个数据中心部署了数据采集系统,采集到数据后以消息的方式发送到消息服务器,然后消息服务器再把这条消息路由到上 海的数据中心,再由上海数据中心部署的数据处理系统来处理这条消息.

4.JMS与事务,一定要用JTA事务吗
很多人接触到JTA事务都是从用JMS开始的,毕竟同时要连多个数据库的的系统并不是那么的多!而要用JTA事务的话,就得要在笨重的应用服务器中部署. (当然,你也可以用类似atomikos的轻量级JTA事务管理器),更重要的是,并不是事务本身的技术有多复杂,而是事务的界定,这种事务的界定有时都 不是程序员能决定的事情,需要在设计的时候就要考虑清楚,甚至可能还需要业务人员的参与.(题外话:经常问面试的,用spring的aop做什么?大多数 答:用来管理事务!事务要真这么简单该多好啊!)
我也不是要反对用JTA事务,而是要说明一下,用JMS,并非一定要用JTA事务.这可以分为三种场景:
一,必须用JTA事务,这种情况下,一般消息的接收者只从消息本身获得数据并进行处理.所以必须要保证消息的发送与所依赖的业务保持一致.
二.不需要用事务,这种情况下, 要么是业务无关紧要,例如用JMS来记录日志.要么是发送的消息仅仅是一个作为后续业务处理的一个触发器!消息接收者仅仅是从消息中获得一个id,然后根 据这个id去查询所依赖的其它数据进行业务处理.即使消息丢失也没关系,可以通过其它的机制来补偿.
三.消息丢失可以通过补偿事务来完成.这个依赖与具体实现,就不详细说了.

5.处理消息永远比发送消息慢!
要保证你的JMS应用稳定的运行,那么你必须在开发,部署的时候时刻重视这个问题.
首先,需要把发送消息的连接池与接收消息的连接池分开.以避免接收消息的连接过过而导致发送消息的应用拿不到连接.
在一个连接上并发的处理消息,而不是连接打开,处理一个消息,马上关闭连接.
合理的设置消息的过期时间,否则消息日积月累,最终超出queue的size
对于非关键业务的消息处理,可以采用异步处理的方法:接收到消息后并不是立刻处理,而是放到一个任务池或者线程池中处理.如果消息处理失败,则把消息重新发送回队列中.