一句话定义：消息队列（Message Queue，MQ）是程序之间传递任务的中间缓冲带——发送方把任务放进队列就立刻返回，接收方按自己的节奏取出处理，双方互不等待。
从一个点单场景说起
在餐厅里，服务员记下客人点的菜，把单子插到出单架上，转身去招呼下一桌；后厨按顺序取单、按能力出菜。服务员不需要站在灶台边等菜做好，后厨也不会因为一瞬间来了二十桌客人就崩溃。
消息队列就是这个“出单架”。在 AI 系统里，一次请求可能是“给这段文字生成摘要”“把这张图抠像”“跑一遍模型评估”，耗时从几百毫秒到几分钟不等。如果前端直接调用模型服务并同步等待，就会出三种事故：用户端超时、模型服务被瞬时流量压垮、一次失败导致整条链路重试风暴。把任务先写进队列，前端拿到一个“已受理”的凭据，后台的推理工作进程（Worker）按自己的并发能力一个个取走处理——这就是 AI 任务先排队再处理的根本原因：算力是有限且昂贵的，流量是突发且不可控的。
队列带来的三件事：削峰（尖峰流量摊平到一段时间）、解耦（前端不必知道模型跑在哪张卡上）、可重试（任务失败留在队列里，换个 Worker 再来一次）。
和相邻概念的区别
日常口语里“消息队列”“任务队列”“事件流”常被混用，侧重其实不同：
| 概念 | 核心关注 | 典型形态 |
|---|---|---|
| 消息队列（Message Queue） | 消息的可靠传递与消费 | 一条消息被一个消费者取走 |
| 任务队列（Task Queue / Job Queue） | 任务的执行、重试与状态 | 带进度、失败重试、结果回写 |
| 事件流（Event Stream） | 事件的有序留存与多方订阅 | 日志式追加，可回溯消费 |
在 AI 工程里，常说的“排队”多半是任务队列；而事件流更常用于埋点、监控这类“多方都要看同一份数据”的场景。另外它也和缓存不同：缓存解决“读得快”，队列解决“做得完”。
对从业者和普通人的意义
对工程师，这意味着设计 AI 功能时要先问一句：这个请求必须同步返回吗？能异步的（批量生成、视频渲染、模型评测）就该走队列，并顺手想清楚三件事——任务幂等（重复投递不会做两遍）、队列积压告警、以及给用户的“排队中/处理中”状态反馈。
对普通职场人，这套逻辑随处可见：批量提交的报告生成、后台跑的表格分析、对话框里那个“正在思考…”的转圈，背后往往就是一条队列。看到“排队等待中”不必焦虑，那不是卡住了，而是系统在按自己的节奏稳稳地消化任务。
具体产品的队列深度、并发上限等参数以官方页面为准。