消息系统选型要用本公司的代表性负载做 PoC（概念验证），而不是比较官网峰值。RabbitMQ 偏灵活路由与队列语义，Kafka 偏可回放分区日志与流处理，RocketMQ 偏丰富业务消息类型；三者都需要幂等、容量规划和运维能力。
Table of contents
先把需求量化
| 维度 | 要填写的数值或约束 |
|---|---|
| 吞吐 | 平均/峰值消息每秒、平均/P99 大小 |
| 延迟 | 端到端 P50/P99 与最大可接受时间 |
| 语义 | 是否回放、局部顺序、延迟、事务、复杂路由 |
| 保留 | 最短保留期、最大积压时长、审计要求 |
| 故障 | 允许丢失量、恢复时间、跨可用区要求 |
| 组织 | 现有监控、值班经验、升级和托管能力 |
让 PoC 同时跑稳定负载、突发负载、大消息、热 key 和慢消费者。注入 Leader/Broker 故障、网络延迟和磁盘水位，记录发布确认延迟、堆积年龄、恢复时间、重复与丢失校验结果。
常见事故的处理顺序
积压时先保护 Broker：限制新流量，确认磁盘余量，再定位是消费错误、下游变慢还是分区/队列倾斜。不要盲目增加消费者；若瓶颈是单分区或数据库，消费者只会制造更多竞争。
重复消息先保留原事件 ID，在消费者唯一键处拦截；不要通过缩短 Broker 重试来掩盖非幂等。顺序错乱先检查业务 key、分区变化、并发处理和失败跳过策略。消息“丢失”则逐段核对 Outbox、发布确认、Broker 存储、消费位置和业务提交。
记录决策和退出条件
ADR 至少写候选方案、基准数据、失败注入结果、总拥有成本和淘汰理由。退出条件可写成：“P99 发布确认超过 200ms 或 3 节点故障恢复超过 60 秒，则停止采用”。
无论选择哪种产品，都先运行实验室的幂等消费测试下载，把重复当作正常路径：
mvn -Dtest=DistributedMechanismsTest#outboxAndIdempotentConsumerSurviveDuplicates test下一步
继续阅读08-21 Temporal、Camunda 与持久工作流，判断复杂长流程是否应交给工作流引擎。