无需使用外部存储，如何在多条JMS消息全部处理完成后发送新消息？

核心结论 #

JMS 规范本身没有内置多消息关联聚合的原生能力，你不需要强制依赖关系型数据库实现，但不存在完全不需要外部存储的方案——所有跨消息的状态追踪本质都需要存储做兜底，只是可以选择不同的存储载体来替代独立数据库。

可选替代方案（无需独立关系型数据库） #

1. 复用消息中间件自身的存储能力 #

绝大多数兼容 JMS 规范的主流消息中间件（ActiveMQ、Artemis、RocketMQ 等）都自带内置存储能力，不需要额外搭独立数据库：

• 延迟检查方案：发送 n 条业务消息的同时，额外发送 1 条延迟时间大于业务最大耗时的检查消息，所有消息携带相同 correlation id，检查消息头附带业务消息总数 n。每条业务消息处理完成后，向一个专属的计数队列发送 1 条同 correlation id 的完成标记。检查消息到期后，消费者统计该 correlation id 下的完成标记数量，和 n 一致则发送 COMPLETED 消息，不一致则重新发送延迟检查消息重试。
• 内置 KV 存储方案：很多 MQ 自带轻量 KV 存储能力（比如 ActiveMQ 支持 LevelDB 持久化、Artemis 内置地址计数器），直接把 correlation id 和剩余计数存在 MQ 自带的存储里即可，不需要额外维护数据库。

2. 用分布式缓存替代数据库 #

如果你的环境里已经有 Redis 之类的分布式缓存，直接用它做计数存储即可：

• 发业务消息时，以 correlation id 为 key，总计数 n 为值写入缓存，设置大于业务最大耗时的过期时间
• 工作节点处理完消息后，调用原子减命令 DECR key，如果返回结果为 0，直接发送 COMPLETED 消息
  这个方案性能比关系型数据库高至少一个量级，实现也更简单，不需要维护表结构。

3. 本地内存聚合方案（仅适用于容错要求低的场景） #

如果你的业务允许小概率漏发/重复发 COMPLETED 消息，且下游消费逻辑天然幂等，可以用无外部存储的变体：

• 每条业务消息头都附带总计数 n，工作节点处理完消息后向一个公共的聚合 Topic 广播完成消息
• 所有服务节点都监听这个聚合 Topic，在本地内存维护 correlation id 的剩余计数，只要某个节点的计数减到 0，就发送 COMPLETED 消息
  这个方案的问题是节点宕机可能丢失本地计数导致漏发通知，多个节点可能同时计数到 0 导致重复发通知，只适合非核心场景。

原始方案的优化建议 #

你最开始的朴素实现其实是可靠性、兼容性最高的方案，如果没有特殊的性能瓶颈不需要完全替换，只需要把计数的数据库操作改成异步批量提交，或者把数据库换成缓存，就能满足绝大多数生产场景的需求。

内容的提问来源于stack exchange，提问作者Matthias