activemq

最新推荐文章于 2025-06-17 20:38:12 发布

菜鸡旭旭

最新推荐文章于 2025-06-17 20:38:12 发布

阅读量210

点赞数

CC 4.0 BY-SA版权

分类专栏： jms 文章标签： ActiveMq

本文链接：https://blog.youkuaiyun.com/fengyuhan123/article/details/79485699

jms 专栏收录该内容

1 篇文章

订阅专栏

不存在jms时的一些缺点
消息的同步性
client server生命周期耦合
点对点通信

jms全部都只给出了接口

它的实现由ActiveMQ RabbitMQ

常用术语
Provider/MessageProvider：生产者

Consumer/MessageConsumer：消费者

PTP：Point To Point，点对点通信消息模型

Pub/Sub：Publish/Subscribe，发布订阅消息模型

Queue：队列，目标类型之一，和PTP结合

Topic：主题，目标类型之一，和Pub/Sub结合

ConnectionFactory：连接工厂，JMS用它创建连接

Connnection：JMS Client到JMS Provider的连接

Destination：消息目的地，由Session创建

Session：会话，由Connection创建，实质上就是发送、接受消息的一个线程，因此生产者、消费者都是Session创建的

conf里面是配置文件，重点关注的是activemq.xml、jetty.xml、jetty-realm.properties。

在登录ActiveMQ Web控制台需要用户名、密码信息；在JMS CLIENT和ActiveMQ进行何种协议的连接、端口是什么等这些信息都在上面的配置文件中可以体现。

data目录下是ActiveMQ进行消息持久化存放的地方，默认采用的是kahadb，当然我们可以采用leveldb，或者采用JDBC存储到MySQL，或者干脆不使用持久化机制。

webapps，注意ActiveMQ自带Jetty提供Web管控台

lib中ActiveMQ为我们提供了分功能的JAR包，当然也提供了activemq-all-5.14.4.jar

实际上，这里是存在安全隐患的，也就是任何人一旦知道MQ的地址，就可以连接访问了，我们可以在activemq.xml中配置指定的用户、密码才能访问ActiveMQ。

关于broker_bind_url，默认就是tcp://localhost:61616，说明是采用TCP协议，61616端口。其实对于ActiveMQ不仅仅支持TCP协议，还有其他协议，开启了多个端口。

作者：张丰哲
链接：https://www.jianshu.com/p/ecdc6eab554c
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

Session，用于发送和接受消息，而且是单线程的，支持事务的。如果Session开启事务支持，那么Session将保存一组信息，要么commit到MQ，要么回滚这些消息。Session可以创建MessageProducer/MessageConsumer。

所谓消息目标，就是消息发送和接受的地点，要么queue，要么topic。

设置持久化方式

须close connection，只有这样ActiveMQ才会释放资源！

消费者的代码和上面非常类似，只不过就是创建MessageConsumer进行receive而已，注意receive()/receive(long)/receiveNoWait()，这些说明消费者可以采用阻塞模式、非阻塞模式接受消息。

作者：张丰哲
链接：https://www.jianshu.com/p/ecdc6eab554c
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

在通过Connection创建Session的时候，需要设置2个参数，一个是否支持事务，另一个是签收的模式。

签收模式

什么是签收？通俗点说，就是消费者接受到消息后，需要告诉消息服务器，我收到消息了。
当消息服务器收到回执后，本条消息将失效。因此签收将对PTP模式产生很大影响。
如果消费者收到消息后，并不签收，那么本条消息继续有效，很可能会被其他消费者消费掉！

AUTO_ACKNOWLEDGE：表示在消费者receive消息的时候自动的签收

CLIENT_ACKNOWLEDGE：表示消费者receive消息后必须手动的调用acknowledge()方法进行签收

DUPS_OK_ACKNOWLEDGE：签不签收无所谓了，只要消费者能够容忍重复的消息接受，当然这样会降低Session的开销

，采用手动的方式较自动的方式可能更好些，因为接收到了消息，并不意味着成功的处理了消息，假设我们采用手动签收的方式，只有在消息成功处理的前提下才进行签收，那么只要消息处理失败，那么消息还有效，仍然会继续消费，直至成功处理！

在上面的code当中，我们创建生产者的时候，指定了Destination，设置了持久化方式，实际上这些都可以不必指定的，而是到send的时候指定。而且在实际业务开发中，往往根据各种判断，来决定将这条消息发往哪个Queue，因此往往不会在MessageProducer创建的时候指定Destination。

TTL，消息的存活时间，一句话：生产者生产了消息，如果消费者不来消费，那么这条消息保持多久的有效期

priority，消息优先级，0-9。0-4是普通消息，5-9是加急消息，消息默认级别是4。注意，消息优先级只是一个理论上的概念，并不能绝对保证优先级高的消息一定被消费者优先消费！也就是说ActiveMQ并不能保证消费的顺序性！

deliveryMode，如果不指定，默认是持久化的消息。如果可以容忍消息的丢失，那么采用非持久化的方式，将会改善性能、减少存储的开销。

作者：张丰哲
链接：https://www.jianshu.com/p/ecdc6eab554c
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

本篇主要讨论的话题是：消息的顺序消费、JMS Selectors、消息的同步/异步接受方式、Message、P2P/PubSub、持久化订阅、持久化消息到MySQL以及与Spring整合等知识。

我们已经明确知道了ActiveMQ并不能保证消费的顺序性，即便我们使用了消息优先级。

有些场景又是需要对消息进行顺序消费的，比如：用户从下单、到支付、再到发货等。如果使用ActiveMQ该如何保证消费的顺序性呢？

仅需要保持局部有效

我们可以根据用户ID简单做一个HASH，将消息定位到不同的队列上，也就意味着同一个用户的消息将发往同一个队列。这样做的好处在于，多个队列之间可以并行处理。

然后，在队列上可以对一段时间上的消息按照用户分组进行排序，这只是一个少量消息的局部排序而已，比如Queue-A上有一个用户的3条消息（订单消息msg1、支付消息msg2、发货消息msg3），那么，msg1将交给订单业务系统，处理完成后，msg2交给支付系统，处理完成后，msg3交给发货系统。虽然这个处理过程是同步的（一条消息处理完，在接着处理），但是它的并发性，系统的处理能力并没有下降！为什么这么说呢？

作者：张丰哲
链接：https://www.jianshu.com/p/f7a7105b3c27
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

RocketMQ在消费顺序性这块要比ActiveMQ要强大些，后期在RocketMQ专题中再为大家介绍。

JMS Selectors，即消息选择器。

消息的接受，我们已经知道，可以通过消费者的receive()/receive(long time)/receiveNoWait()，这种方式是client端主动接受消息，可以理解为消息的同步接受。

要知道这种同步的消息接受方式，是让我们很难受的，我们不得不写一个死循环来不断接受消息。

消息的异步接受是指当消息到达时，ActiveMQ主动通知客户端。
可以通过注册一个实现了MessageListener接口的对象到MessageConsumer。
MessageListener只有一个必须要实现的方法，即onMessage。在发往Destination的消息时，会调用该方法。

作者：张丰哲
链接：https://www.jianshu.com/p/f7a7105b3c27
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

这种异步接受“貌似”是ActiveMQ主动的推送消息给消费者，其本质还是消费者轮询消息服务器导致的，只不过这个过程被封装了！

JMS程序的核心在于，生产和消费的消息能够被其他程序所使用到。JMS Message是一个既简单又不乏灵活的基本格式，由消息头、属性、消息体3部分组成。

注意，在消费者端，我们接受到消息后，一般需要通过instanceof来判断类型后在进行处理！

在ActiveMQ中，还存在一类临时消息，就是通过创建临时队列/临时主题，如果Connection一旦关闭，那么临时目标就关闭，消息内容也就消失。了解下即可，实际中并不适用。

P2P
这里写图片描述

生产者端发送一条消息，消费者端只会有一个消费者消费这个消息。好像打电话，一对一通信！
这里写图片描述

P2P、Pub/Sub在代码上的区别点仅仅在于，目标类型的创建是createQueue or createTopic，其他一切照旧！

对于订阅模式，对订阅者提出了特殊的要求，要想收到消息，必须先订阅，而且订阅进程必须一直处于运行状态！实际上，有时候消费者重启了下，那么这个消费者将丢失掉一些消息，那么能否避免这样的情况呢？ActiveMQ已经替我们想好了，就是持久化订阅！

作者：张丰哲
链接：https://www.jianshu.com/p/f7a7105b3c27
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

持久化订阅
每一个持久化订阅者都应该有一个唯一的ID作为标示以及要在哪个Topic上进行持久化订阅，一旦这些信息告知MQ之后，那么以后不论持久化订阅者在不在线，那么他的消息会暂存在MQ，以后都会发给他！

在前文中已经提及默认情况下，ActiveMQ是开启持久化消息机制的，并且是持久化到kahadb的，但是”很可惜”kahadb对我们不是很友好的可视化，其实ActiveMQ提供了配置的方式让我们来选择持久化消息到哪里，这里我以到MySQL为例来说明。(实际上ActiveMQ已经在conf配置文件中提供了相应的例子，我这里就简单说明下)

作者：张丰哲
链接：https://www.jianshu.com/p/f7a7105b3c27
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
这里写图片描述
在activemq.xml的节点中增加MySQL信息
注意到这个bean的id，这个是要被引用的。

注释kahadb，启用持久化到MySQL配置

实际中，我们会持久化到哪里呢？一般情况下，比如到kahadb，比如到leveldb，因为这些数据库的性能要较MySQL更高些，我们并不关心消息的“可视化”，更加关心的是消息在持久化的同时更加高效！

注意从ActiveMQConectionFactory到PooledConnectionFactory，到Spring提供的SingleConnectionFactory，就是一个适配的过程。

注意Spring的套路经常是这样的，提供XxxTemplate，比如HibernateTemplate，对于JMS，提供了JmsTemplate。

生产者应该持有JmsTemplate进行发送消息。

消费者，提供监听器、监听的目的地、连接工厂即可。

SpringTest + Junit4还提供了很多功能强大的地方，比如可以设置数据库事务。如果我们在测试的过程结束后，希望回滚数据库的话，很简单，只需要在相应方法上打上注解即可。