Docker安装ActiveMQ镜像以及通过Java生产消费activemq示例_docker activemq-CSDN博客

背景

周末由于服务器异常宕机，导致业务系统重启后出现ActiveMQ中的数据没有被正常消费，运维认为是消息积压，便联系博主排查。

最终发现并不存在消息积压，是因为采用ActiveMQ Topic模式生产消费消息，服务器宕机期间没有消费者正常消费topic数据，导致数据丢失，最后通过上游补发消息修复。

ActiveMQ中的Queue（队列）和Topic（主题）是两种不同的消息传递模式，它们各自具有独特的特点和适用场景。

消息传递模式

    Queue（队列）：

        队列是点对点（Point-to-Point）的消息传递模式。

        一条消息只能被一个消费者接收。

        如果当前没有消费者，消息会被存储在队列中，等待消费者消费。

        消费者可以随时从队列中读取消息，并且消息的消费顺序与发送顺序一致。

    Topic（主题）：

        主题是发布/订阅（Publish/Subscribe）的消息传递模式。

        一条消息可以被多个订阅者接收。

        如果当前没有订阅者，消息会被丢弃（除非配置了持久订阅）。

        订阅者只能接收到订阅之后发布的消息（除非配置了持久订阅，允许消费未激活状态时发送的消息）。

消息存储与持久化

    Queue：

        消息默认会存储在ActiveMQ服务器上，直到被消费者消费。

        支持消息持久化，即使ActiveMQ服务器重启，已持久化的消息也不会丢失。

    Topic：

        默认情况下，Topic不保存消息，消息是无状态且不落地的。

        支持持久订阅，但即使配置了持久订阅，消息的存储也与Queue有所不同，它主要依赖于订阅者的持久化机制。

生产者与消费者关系

    Queue：

        生产者与消费者之间没有时间上的相关性。生产者发送消息时，无需考虑消费者是否在线或已订阅。

        消费者可以在之后的任意时间消费队列中的消息。

    Topic：

        生产者与消费者之间有一定的时间相关性。订阅者只能接收到订阅之后发布的消息。

        如果生产者发送消息时，没有订阅者在线，那么这些消息会被丢弃（除非配置了持久订阅）。

使用场景

    Queue：

        适用于需要确保消息被唯一消费者处理的场景，如订单处理、任务调度等。

        适用于消费者需要按顺序处理消息的场景。

    Topic：

        适用于需要将消息广播给多个消费者的场景，如实时通知、事件驱动架构等。

        适用于消费者需要实时接收并处理消息的场景。

代码测试

Queue 示例，这里是先启动的生产者，后启动的消费者

生产者日志：

消费者日志：

可以看到是可以从头开始消费的

Topic示例，同样先启动的生产者，后启动的消费者

生产者日志：

消费者日志

可以看到启动前的数据没有被消费到

以上就是ActiveMQ的生产消费机制的内容了，有问题的地方也欢迎大家一起交流沟通~