activemq系列-概述

TL;DR 消息中间件解决两个核心问题——解耦和削峰，ActiveMQ是JMS规范最完整的实现

ActiveMQ 是 Apache 旗下的开源消息中间件（Message-Oriented Middleware，MOM），也是 JMS（Java Message Service）1.1 规范的完整实现。本文是 ActiveMQ 系列文章的开篇，先讲清楚消息中间件是什么、解决什么问题，再介绍 JMS 的核心概念，为后续深入学习 ActiveMQ 的具体特性打好基础。

消息中间件解决什么问题？

消息中间件是分布式系统中非常常见的组件。它的核心定位是作为应用程序之间的中介——各个应用不直接互相通信，而是通过消息中间件来传递消息。

两个最核心的价值：解耦和削峰。

解耦

想象一个用户登录的场景：登录成功后，可能会有多个下游系统需要响应——给用户发欢迎消息、更新推荐算法、同步用户数据到数据仓库、触发风控检查……这些操作跟登录本身没有直接关系，如果把逻辑全部写在登录模块里，不仅代码会变成一锅粥，登录的响应时间也会变得不可接受。

引入消息中间件后，登录模块只需要在验证成功后发一条”用户已登录”的消息，其他系统各自监听这个消息，独立执行自己的业务逻辑。登录模块不再需要知道下游有哪些系统，新增一个消费者也无需修改登录代码。

削峰

系统的资源是按日常流量分配的，不可能按秒杀级别的峰值去配置。当瞬时流量远超系统处理能力时，与其让请求直接打到数据库把整个系统拖垮，不如让消息先在中间件里排队，下游系统按照自己的能力慢慢消费。

举个例子：秒杀场景下，1 秒内涌入 10 万个下单请求，但数据库每秒只能处理 1000 个。用消息中间件作为缓冲，请求先写入消息队列，后台服务按 1000 QPS 匀速处理，保证系统不被冲垮。

消息传递的两种模式

消息中间件一般支持两种消息传递模式：

点对点模式（P2P / Queue）

在 JMS 中对应 Queue（队列），有三个特点：

一条消息一个消费者：多个消费者可以监听同一个 Queue，但每条消息只会被其中一个消费
时间解耦：发送者发消息时，接收者不需要在线。消息会持久化在队列中，等待接收者上线后消费
需要确认：消费者成功处理消息后，需要向队列发送应答（ACK），消息才会被标记为已消费

典型场景：订单处理、异步任务分发。

发布-订阅模式（Pub/Sub / Topic）

在 JMS 中对应 Topic（主题）：

一条消息多个消费者：发布者发出消息后，所有订阅了该 Topic 的消费者都会收到
时间耦合：订阅者必须保持在线才能收到消息（除非使用持久订阅，Durable Subscription）
广播特性：适合一对多通知的场景

典型场景：配置变更通知、实时推送、事件广播。

Queue vs Topic 对比

特性	Queue	Topic
消费模式	一条消息一个消费者	一条消息广播给所有订阅者
时间依赖	无（消息持久化）	有（订阅者需在线，持久订阅除外）
消息确认	需要 ACK	发布即完成
典型场景	异步任务、削峰	事件通知、实时推送