JMS学习笔记2

来源:互联网 发布:python 字符串连接数字 编辑:程序博客网 时间:2024/05/29 16:02

开发JSM 的步骤

广义上说,一个 JMS 应用是几个JMS 客户端交换消息,开发JMS 客户端应用由以下几步构成:
用 JNDI 得到ConnectionFactory 对象;
用 ConnectionFactory 创建Connection 对象;
用 Connection 对象创建一个或多个JMS Session;
用 JNDI 得到目标队列或主题对象,即Destination 对象;
用 Session 和Destination 创建MessageProducer 和MessageConsumer;
通知 Connection 开始传送消息。


消息的同步和异步接收

消息的同步接收是指客户端主动去接收消息,客户端可以采用 MessageConsumer的receive 方法去接收下一个消息。
消息的异步接收是指当消息到达时,ActiveMQ 主动通知客户端。客户端可以通过注册一个实现MessageListener 接口的对象到MessageConsumer。MessageListener 只有一个必须实现的方法—— onMessage,它只接收一个参数,即Message。在为每个发送到Destination 的消息实现onMessage 时,将调用该方法。


消息选择器

JMS 提供了一种机制,使用它,消息服务可根据消息选择器中的标准来执行消息过滤。生产者可在消息中放入应用程序特有的属性,而消费者可使用基于这些属性的选择标准来表明对消息是否感兴趣。这就简化了客户端的工作,并避免了向不需要这些消息的消费者传送消息的开销。然而,它也使得处理选择标准的消息服务增加了一些额外开销。
消息选择器是用于 MessageConsumer 的过滤器,可以用来过滤传入消息的属性和消息头部分(但不过滤消息体),并确定是否将实际消费该消息。按照JMS 文档的说法,消息选择器是一些字符串,它们基于某种语法,而这种语法是SQL-92 的子集。可以将消息选择器作为MessageConsumer 创建的一部分。
Java 客户端:
public final String SELECTOR = “JMSType = ‘TOPIC_PUBLISHER’”;
该选择器检查了传入消息的JMSType 属性,并确定了这个属性的值是否等于TOPIC_PUBLISHER。如果相等,则消息被消费;如果不相等,那么消息会被忽略。


可靠性机制

发送消息最可靠的方法就是在事务中发送持久性的消息,ActiveMQ 默认发送持久性消息。结束事务有两种方法:提交或者回滚。
当一个事务提交,消息被处理。如果事务中有一个步骤失败,事务就回滚,这个事务中的已经执行的动作将被撤销。接收消息最可靠的方法就是在事务中接收信息,不管是从PTP 模式的非临时队列接收消息还是从Pub/Sub 模式持久订阅中接收消息。
对于其他程序,低可靠性可以降低开销和提高性能,例如发送消息时可以更改消息的优先级或者指定消息的过期时间。
消息传送的可靠性越高,需要的开销和带宽就越多。
性能和可靠性之间的折衷是设计时要重点考虑的一个方面。可以选择生成和使用非持久性消息来获得最佳性能。另一方面,也可以通过生成和使用持久性消息并使用事务会话来获得最佳可靠性。在这两种极端之间有许多选择,这取决于应用程序的要求。

基本可靠性机制

控制消息的签收(Acknowledgment)
客户端成功接收一条消息的标志是这条消息被签收。成功接收一条消息一般包括如下三个阶段:
1.客户端接收消息;
2.客户端处理消息;
3.消息被签收。签收可以由MessageProvider发起,也可以由客户端发起,取决于Session 签收模式的设置。


在带事务(逻辑单元由事务控制)的 Session 中,签收自动发生在事务提交时。如果事务回滚,所有已经接收的消息将会被再次传送。
在不带事务的Session 中,一条消息何时和如何被签收取决于Session 的设置。
1.Session.AUTO_ACKNOWLEDGE
当客户端从 receive 或onMessage 成功返回时,Session 自动签收客户端的这条消息的收条。在AUTO_ACKNOWLEDGE 的Session 中,同步接收receive 是上述三个阶段的一个例外,在这种情况下,收条和签收紧随在处理消息之后发生。
2.Session.CLIENT_ACKNOWLEDGE
客户端通过调用消息的 acknowledge 方法签收消息。在这种情况下,签收发生在Session 层面:签收一个已消费的消息会自动地签收这个Session 所有已消费消息的收条。
3.Session.DUPS_OK_ACKNOWLEDGE
此选项指示 Session 不必确保对传送消息的签收。它可能引起消息的重复,但是降低了Session 的开销,所以只有客户端能容忍重复的消息,才可使用(如果ActiveMQ 再次传送同一消息,那么消息头中的JMSRedelivered 将被设置为true)


消息传送模式

ActiveMQ 支持两种消息传送模式:PERSISTENT 和NON_PERSISTENT 两种。
1.PERSISTENT(持久性消息)
这是 ActiveMQ 的默认传送模式,此模式保证这些消息只被传送一次和成功使用一次。对于这些消息,可靠性是优先考虑的因素。可靠性的另一个重要方面是确保持久性消息传送至目标后,消息服务在向消费者传送它们之前不会丢失这些消息。这意味着在持久性消息传送至目标时,消息服务将其放入持久性数据存储。如果消息服务由于某种原因导致失败,它可以恢复此消息并将此消息传送至相应的消费者。虽然这样增加了消息传送的开销,但却增加了可靠性。
2.NON_PERSISTENT(非持久性消息)
保证这些消息最多被传送一次。对于这些消息,可靠性并非主要的考虑因素。此模式并不要求持久性的数据存储,也不保证消息服务由于某种原因导致失败后消息不会丢失。
有两种方法指定传送模式:
1.使用setDeliveryMode 方法,这样所有的消息都采用此传送模式;
2.使用send 方法为每一条消息设置传送模式;







原创粉丝点击