JMS - JMS​应​用​领​域 应用场景

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事务.这可以分为三种场景:

1. 必须用JTA事务,这种情况下,一般消息的接收者只从消息本身获得数据并进行处理.所以必须要保证消息的发送与所依赖的业务保持一致.

2. 不需要用事务,这种情况下, 要么是业务无关紧要,例如用JMS来记录日志.要么是发送的消息仅仅是一个作为后续业务处理的一个触发器!消息接收者仅仅是从消息中获得一个id,然后根据这个id去查询所依赖的其它数据进行业务处理.即使消息丢失也没关系,可以通过其它的机制来补偿.

3. 消息丢失可以通过补偿事务来完成.这个依赖与具体实现,就不详细说了. 

5.处理消息永远比发送消息慢!

要保证你的JMS应用稳定的运行,那么你必须在开发,部署的时候时刻重视这个问题. 

 - 首先,需要把发送消息的连接池与接收消息的连接池分开.以避免接收消息的连接过过而导致发送消息的应用拿不到连接. 

 - 在一个连接上并发的处理消息,而不是连接打开,处理一个消息,马上关闭连接.

 - 合理的设置消息的过期时间,否则消息日积月累,最终超出queue的size 

 - 对于非关键业务的消息处理,可以采用异步处理的方法:接收到消息后并不是立刻处理,而是放到一个任务池或者线程池中处理.如果消息处理失败,则把消息重新发送回队列中.

  JMS的运用场景？ 

   用户系统负责维护用户信息，文档系统负责维护文档信息，但是当用户删除的时候，需要将他所撰写的文档信息也删除的时候，在用户管理模块调用文档管理模块的接口，会造成用户模块和业务模块紧耦合。

   这个时候可以使用J MS技术来将紧耦合转化为松耦合，具体做法是用户系统在删除，修改用户的时候往JMS服务器发送更新消息，又业务系统监听这些消息，然后按照自己的业务逻辑来进行相应的处理。

   即组件A做了一件事情往消息服务器上发送了一个通知，组件B监听到了消息，处理自己的业务逻辑。