消息队列

同步调用 vs 消息队列

电商下单是理解消息队列价值的经典场景。用户点击「立即购买」，如果所有后续操作——扣库存、生成订单、扣款、发短信通知、更新积分、触发仓库备货——都同步串行执行，一次下单可能要 2-3 秒，还会因为短信服务抖动导致整个链路失败。

引入消息队列后，核心操作（扣库存、生成订单）同步完成，其余发短信、更新积分、通知仓库全部变成消息投递，各自的消费者独立处理，互不影响。用户感知的下单时延降到 200ms 以内，短信服务挂了也不影响下单成功。这就是「异步解耦」和「流量削峰」的核心价值。[1]

Kafka 与传统队列的区别

RabbitMQ（2007 年）是传统消息队列的代表：消息推送给消费者，消费后从队列删除，适合任务队列和 RPC 解耦。Apache Kafka（2011 年，LinkedIn 开源）的设计思路完全不同——它把消息写入磁盘日志并长期保留，消费者用 offset 记录自己读到哪里，消息可以被多个消费者组重复读取，适合大数据流处理。Kafka 单集群可达每秒百万级消息吞吐，LinkedIn 生产环境日均消息量超过万亿条。

阿里巴巴 2012 年开源的 RocketMQ 在 Kafka 基础上加入了事务消息和定时消息，解决了电商场景下分布式事务问题，是国内互联网公司使用最广泛的消息队列之一。