消息中间件选型是什么
消息中间件选型要比对投递模型、顺序性、延迟、吞吐与运维复杂度，而不是只看单点指标。高吞吐、可回放、按分区保序的流式平台适合事件管道与日志场景；路由灵活、支持复杂交换机模型的传统消息队列适合任务分发与业务解耦；云托管队列省去运维，但受平台能力与配额约束。真实系统里多种中间件并存很常见，前提是团队能承担相应的运维与监控成本。
基本信息
| 投递模型 | 点对点队列、发布订阅、持久化流式回放 |
|---|---|
| 顺序性 | 分区内有序是常见保证；全局有序代价高，先确认业务是否真的需要 |
| 延迟 | 端到端投递延迟含网络、批处理与消费端处理 |
| 可靠性 | 副本数、确认机制、刷盘策略决定消息丢失风险 |
| 运维 | 集群规模、扩缩容、监控指标与故障恢复演练成本 |
典型使用场景
- 业务解耦：订单创建后异步通知库存、通知与积分，避免同步调用链过长
- 削峰填谷：入口流量高峰先入队，消费端按固定速率处理
- 事件溯源与回放：需要按时间重放历史事件重建状态时选流式平台
- 任务分发：把耗时任务派发给工作进程，按队列长度动态扩容
- 跨系统集成：与外部系统对接时用可靠队列替代直接调用
- 日志与埋点管道：高吞吐写入，下游多消费者各自处理
选型评估维度
| 维度 | 关注点 | 验证方法 |
|---|---|---|
| 投递模型 | 队列、发布订阅、流式回放是否满足消费模式 | 按业务消费模式逐条核对 |
| 顺序 | 分区内顺序还是全局顺序，是否需要严格保序 | 压测乱序率与重排逻辑 |
| 延迟 | 端到端投递延迟及其在批量开启后的变化 | 压测 P99 而非平均值 |
| 可靠性 | 副本与确认机制下的实际丢失窗口 | 故障注入：杀节点、断网后核对消息 |
| 运维 | 集群规模、扩容方式、监控覆盖与故障恢复时长 | 演练扩缩容与主从切换 |
接入前必须定义的四件事
接入前必须定义的四件事
# 1 消费语义：至少一次还是至多一次，重复投递由谁去重
# 2 顺序要求：业务键到分区的映射规则，跨分区不保序的补偿方式
# 3 失败处理：重试次数、退避策略、超过上限后转死信还是丢弃
# 4 时效要求：端到端延迟目标，积压告警阈值与扩容触发条件
# 补充：消息体大小上限、保留时长、是否需要回放历史数据先定义消费语义再选型：幂等、重试与死信这些语义在不同中间件上的支持程度差异明显，选完再补往往要改应用代码。
顺序性要按业务粒度确认：多数场景只需要按业务主键保序，追求全局有序会显著牺牲吞吐，通常得不偿失。