32 lines
1.6 KiB
Markdown
32 lines
1.6 KiB
Markdown
# ADR-0003：采用 RocketMQ 5.x 作为唯一消息队列
|
|
|
|
- 状态：accepted
|
|
- 日期：2026-08-13
|
|
- 关联功能：GOV-008
|
|
|
|
## 背景
|
|
|
|
项目此前在架构和环境模板中约定 RabbitMQ，但尚未实现消息客户端、Topic 或业务消费流程。产品需要分钟级盘中分析、定时采集、指标计算、AI 分析和失败重试，决定在实现前统一切换到 RocketMQ。
|
|
|
|
## 决策
|
|
|
|
- 项目唯一消息队列为 RocketMQ 5.x，不维护 RabbitMQ 双栈。
|
|
- Scheduler 和 Worker 只依赖项目级 `MessageBusAdapter` 与版本化事件契约。
|
|
- Node.js 客户端优先通过 RocketMQ 5.x Proxy 接入；若改用直接 NameServer/Broker 客户端，必须通过兼容性和可靠性验证。
|
|
- Topic、Tag、Producer Group、Consumer Group、顺序键、重试与死信语义必须在功能设计中明确。
|
|
- 本地和生产基础设施独立于应用发布；NameServer、Broker、Proxy 不随应用版本自动创建或删除。
|
|
|
|
## 原因
|
|
|
|
RocketMQ 对定时/延迟任务、重试、死信、顺序消息和后续任务规模扩展更符合预期。Adapter 边界用于控制 Node 客户端成熟度和接入协议变化带来的风险。
|
|
|
|
## 代价
|
|
|
|
- 本地和生产运维复杂度高于单节点 RabbitMQ，需要区分 NameServer、Broker 和 Proxy。
|
|
- Node.js 生态需要在 Server 脚手架阶段单独验证，不能仅凭 NameServer 端口可达决定客户端可用。
|
|
- 所有消费者必须按至少一次投递设计幂等和受控重放。
|
|
|
|
## 验证
|
|
|
|
GOV-008 只验证配置、文档契约和本机 NameServer 状态。真实 Topic 生产/消费必须在 Broker/Proxy 可用且 Server 客户端选定后补充契约测试。
|