发送成功不等于完成：消息队列的真实运作机制
内容提要
本文阐述消息队列的实质：发送成功不等于业务完成。MQ用于解耦、异步和削峰，但会带来重复消费、消息丢失、乱序和积压等成本。文章对比Kafka、RabbitMQ、RocketMQ的高可用机制，强调幂等、可靠投递、顺序保证与积压处理，并归纳可扩展、持久化、高可用和可靠性的架构设计要点。
延伸解读
异步响应的边界：发送成功≠业务完成
文章强调，消息发送成功仅表示后续处理被触发，并不代表下游业务已全部成功。API 应明确响应语义是“已接受”“本地处理成功”还是“全流程完成”。异步化虽能缩短主请求路径，但一致性需额外设计重试、补偿与结果校验，否则部分下游失败会导致业务暂时或持续不一致。
削峰填谷的代价：积压是等待而非消失
以 5000 条/秒峰值、2000 条/秒处理能力为例，一小时峰值会积压 1080 万条消息，峰值过后需约 92 分钟才能清空。这说明 MQ 只是把突发压力转化为队列等待，并未消除工作量。前提是峰值临时且长期平均输入不超过处理能力，同时 MQ 需有足够容量和保留时间容纳积压。
高可用不等于零丢失：确认与可见性边界不同
Kafka 中生产者收到 acks=all 成功响应，仅表示当前 ISR 已完成复制，消费者能否读取还受高水位（HW）限制；acks=1 成功也不代表消息已对消费者可见。RabbitMQ 持久化需队列 durable 与消息 persistent 配合，且持久化确认前崩溃仍可能丢失。高可用机制需结合确认模式、复制策略与消费确认时机综合评估。
幂等是重复消费的兜底，而非可选项
业务处理完成与 MQ 记录完成存在时间差，崩溃或确认丢失会导致重复投递。文章建议用唯一消息 ID 去重，且发送重试应复用同一 ID；数据库唯一键可将去重记录与业务操作放入同一事务，避免“先写标记后业务失败”的窗口。但外部支付、短信等操作仍需对方接口幂等配合，本地事务无法单独保证。
Q&A
消息队列发送成功就代表业务完成了吗？
不代表。发送成功只表示消息已触发后续处理，并不保证所有下游业务操作都成功。API应明确响应含义是“已接受”、“本地处理成功”还是“整个工作流完成”。
引入消息队列会带来哪些额外成本？
主要成本包括：可用性依赖（MQ故障可能影响主流程）、系统复杂度增加（需处理重复消费、消息丢失、乱序、重试和积压）、以及一致性挑战（部分下游成功可能导致数据不一致，需重试和补偿）。
Kafka如何保证高可用？
Kafka通过分区和副本机制实现高可用。每个分区有多个副本，分布在不同的broker上，其中leader处理读写，followers从leader拉取数据同步。当leader失效时，从ISR中选举新leader。配合acks=all和min.insync.replicas可确保消息被足够多的副本确认。
如何防止消息被重复消费？
核心是实现幂等性，即同一操作执行多次结果一致。常用方法包括：使用唯一业务ID去重、数据库唯一约束、Redis SETNX记录处理标记、以及将去重记录与业务操作放在同一事务中。注意发送重试应复用同一ID，且去重标记需在业务成功后写入。
RabbitMQ如何确保消息不丢失？
需从三个环节保障：生产者使用publisher confirm或事务确认发送成功；broker端设置队列持久化和消息持久化，并配合confirm机制确保落盘；消费者关闭自动ack，在处理完成后手动确认。同时需考虑重试和幂等。
消息队列如何保证消息顺序？
通常只需保证同一业务实体（如订单ID）的消息顺序。方法包括：将需顺序处理的消息发送到同一队列并由单一消费者处理；或在消费者内按业务键哈希到多个内存队列，每个队列由单独worker顺序处理。注意全局顺序会牺牲吞吐量。
