消息队列
消息队列用于跨模块、跨服务的异步解耦。RuoYi Office 框架侧提供 Redis Stream、Redis Pub/Sub、RabbitMQ、RocketMQ 等接入能力，核心代码位于 yudao-framework/yudao-spring-boot-starter-mq，多租户场景还在租户 Starter 中提供 RabbitMQ/RocketMQ 的租户上下文传递。
框架能力
| 类型 | 关键类 | 说明 |
|---|---|---|
| Redis Stream | RedisMQTemplate、AbstractRedisStreamMessageListener | 适合可靠消费、待处理消息重投、消费组 |
| Redis Pub/Sub | AbstractRedisChannelMessageListener | 适合轻量广播通知 |
| RabbitMQ | YudaoRabbitMQAutoConfiguration | 适合 AMQP 队列场景 |
| RocketMQ | 租户 MQ Hook/Initializer | 适合高吞吐消息、顺序或事务消息扩展 |
| 消息补偿 | RedisPendingMessageResendJob、RedisStreamMessageCleanupJob | 处理 pending 消息重投和历史消息清理 |
典型链路
设计建议
- 消息体只放必要字段：优先放业务 ID、事件类型、租户、时间戳，消费者再查业务详情。
- 消费者必须幂等：Redis Stream pending 重投、MQ 重试都可能导致重复消费。
- 明确失败策略：失败后是重试、入死信、记录补偿表，还是人工处理，要按业务风险决定。
- 跨租户要传递租户上下文：不要在消费者里默认使用系统租户或空租户。
适用场景
| 场景 | 建议 |
|---|---|
| 站内信/短信/邮件发送 | 可用 MQ 或异步任务削峰，失败要可补偿 |
| 流程通知 | 适合 MQ 解耦 BPM 与业务模块 |
| IoT 设备消息 | 高吞吐场景建议拆专用主题和消费组 |
| 商城订单状态同步 | 必须保证幂等和顺序边界 |
排查清单
| 现象 | 优先检查 |
|---|---|
| 消息没消费 | 消费者是否启动；topic/stream/key 是否一致；消费组是否正确 |
| 重复消费 | 幂等键是否设置；pending 重投是否触发；消费者异常是否反复重试 |
| 租户数据错乱 | 消息是否携带租户；消费 Hook 是否生效 |
| 积压严重 | 消费速度、单条耗时、消费组数量、下游数据库性能 |
