双十一下单那么多，为什么不丢单？

双十一零点，成千上万的人同时下单，后厨再快也做不过来，可网站没有崩，订单也没有丢。靠的是一条排好的队：消息队列（Message Queue，简称 MQ）。下面分 6 步讲清楚。

6 步看懂消息队列

1. 双十一零点#▶ 从这里看

• 上一期的服务端缓存解决的是「读得快」；这一期解决的是「一下子涌来太多要处理的事」。

2. 不排队会怎样#▶ 从这里看

• 前台每收一单就等后厨做完再接下一位，这叫同步。
• 网站也一样：每个请求都等后面处理完才回话，高峰一来，整个系统就卡住，甚至丢单。

3. 取号叫号#▶ 从这里看

• 先把单子放进队列，马上回「已收到」，不等做完，这叫异步。
• 装着号单、按顺序排好的这条队，就是消息队列。前台和后厨各干各的，谁也不用等谁。¹

4. 削峰#▶ 从这里看

• 假设一分钟涌来一万单、后厨一分钟只能做一千单（数字只是示意）：没有队列，后厨当场被冲垮；有了队列，单子先排着，高峰过去再慢慢消化。
• 把突然冲上来的尖峰压平，叫削峰。¹

5. 生产者和消费者#▶ 从这里看

• 往队里放单的叫生产者，从队里取单去做的叫消费者。²
• 不丢单的关键：消费者做完要回一个确认（ack），记下「这条办完了」；RabbitMQ 收到确认才删消息，Kafka 不删消息、改为提交消费位置（offset）。中途出错没确认，消息还在，之后会重新投递、再处理一次。³
• 代价是可能重复：没确认的消息会被重新投递，同一单偶尔会被处理两次，所以消费者要能认出重复（见第十一期「幂等」）。³
• 不同工具的「记号」不一样：RabbitMQ 是确认后删掉消息；Kafka 不删消息，而是记下消费到哪个位置（提交 offset），重启后从记下的位置接着读。⁴
• 「不丢」也有前提：消息要持久化，生产者要等队列回「已存好」的发布确认；队列节点在写盘前挂掉，仍可能丢。³
• 常用的工具，一个叫 Kafka⁵，一个叫 RabbitMQ³。

6. 回顾#▶ 从这里看

• 浏览器缓存：你家冰箱。
• CDN：附近门店。
• 负载均衡：多开的柜台。
• 服务端缓存：后厨备菜台，帮网站省一趟路。
• 消息队列：叫号队伍，帮网站扛住高峰，配好确认和持久化后，订单也不容易丢。

深入一问

异步了，用户怎么知道订单最后成没成？
前台先回的「已收到」只代表单子进了队列。真正处理完以后，系统再通过订单状态、通知或短信告诉你结果，所以你常会看到「订单处理中」。

队列会不会越排越长？
会。如果消费者长期比生产者慢，队列就会一直堆积。削峰只适合「一阵一阵」的高峰；长期忙不过来，还得加消费者（多开几个厨师）。²

易错点

• ❌ 「有了消息队列就是马上处理」→ ✅ 它是先收下、再交给消费者处理；能不能严格按顺序，要看工具和配置（比如 Kafka 只保证同一分区内有序）。换来的是不崩、不丢，代价是要稍等。
• ❌ 「用了消息队列就绝对不丢、不重」→ ✅ 要配好持久化和确认才不容易丢；重新投递还可能重复，消费者要做幂等。
• ❌ 「消息被取走就算处理完了」→ ✅ 要等消费者回确认：RabbitMQ 收到确认才删消息，Kafka 不删消息、改为提交消费位置（offset）；中途出错没确认，消息还在，之后会重新投递、再处理一次。
• ❌ 「削峰能让后厨变快」→ ✅ 后厨速度没变，只是把高峰摊到后面的时间里慢慢做。

参考资料