MQ 解耦生产者和消费者
一个服务不再同步调用另一个服务，而是先发布消息，消费者稍后处理。
消息队列与事件流
2026年免费云端消息队列 (MQ) 与流处理方案对比
消息队列是后端可靠性基础设施。它们缓冲工作、解耦服务、吸收流量峰值，并让任务可以安全重试。适合 webhook 处理、后台任务、IoT 事件、审计日志和异步流程，不适合直接做用户在线实时状态。
快速结论
队列用于异步后端工作，不用于实时 UI。
需要可重放事件日志时，用 Kafka 类 stream。
设备保持轻量 topic 连接时，用 MQTT。
更新时间: 2026-05-22
心智模型
队列、流和发布订阅不同
队列用于分发工作，流保存有序事件日志，发布订阅把消息广播给订阅者。要按投递语义选择。
MQ 不是 WebSocket 聊天
MQ 通常是后端到后端；WebSocket 是面向用户的实时连接。有些服务两者都做，但设计目标不同。
可靠性才是核心能力
重试、顺序、死信队列、幂等、保留时间和背压，比消息数标题更重要。
快速推荐
免费 MQ 与事件流对比表
表格用于快速查看额度。随后要检查投递保证、保留时间、重试和无服务器连接行为。
| 提供商 | 免费存储 | 月流量 | 规格 / 算力 | 连接限制 | 关键限制 | 操作 |
|---|---|---|---|---|---|---|
Ably RealtimePubSub / WebSocket | 每月 6,000,000 条消息 | 突发上限为每秒 500 条消息 | 最多支持 200 个通道，并提供状态恢复相关 SDK | 活跃 WebSocket 连接硬上限 200 | 峰值超过每秒 500 条消息时会直接丢消息 | 访问官网 ↗ |
Upstash Kafka无服务器 Kafka | 每天 25 万次操作 | 最多保留 2 GB 数据 | 原生 REST HTTP API，适合从 Cloudflare Workers 等无状态环境产生日志与事件 | 无连接无状态执行池 | 日配额用尽后会立即硬阻断，直到 UTC 午夜重置 | 访问官网 ↗ |
EMQX Cloud（EMQ）无服务器 MQTT / IoT | 每月 100 万条消息 | 针对小消息负载做了优化 | 内置 SQL 数据集成规则引擎，可自动转发到数据库或 Webhook | 设备并发连接硬锁为 25 | 连续 30 天无流量会直接删除整个集群 | 访问官网 ↗ |
Redis Cloud原生 Redis 内核 | 30 MB 沙箱 | 每月 5 GB 网络流量上限 | 原生支持 Pub/Sub、List 队列和 Stream 数据结构 | 并发客户端连接最大为 30 | 每秒 100 次操作为硬上限；高并发会快速触发限流，14 天无操作会删库 | 访问官网 ↗ |
HiveMQ CloudIoT / MQTT Broker | 固定 100 个设备 | 每月含 10 GB 数据传输 | 全托管 MQTT Broker，默认强制 TLS | 设备并发连接上限 100 | 不提供持久化磁盘存储，客户端离线时容易丢消息 | 访问官网 ↗ |
CloudAMQPRabbitMQ 托管服务 | 每月 100 万条消息 | 队列中最多堆积 20,000 条消息 | 提供专属原生 RabbitMQ 集群实例（Little Lemur 方案） | 物理 Socket 并发连接硬上限 200 | 仅支持 TCP；缺少 HTTP REST 接口，在无服务器场景中容易耗尽连接 | 访问官网 ↗ |
如何选择 MQ
先看投递保证
至多一次、至少一次、顺序、重放和死信行为，比服务商品牌更能决定架构。
消费者必须幂等
可靠系统通常会重试。如果消费者不能安全处理重复消息，队列迟早会暴露这个 bug。
关注保留时间和积压
免费层常限制保留数据或堆积消息。消费者故障会比正常流量更快耗尽额度。
无服务器更偏好 HTTP API
TCP broker 从 VM 访问自然，但函数可能泄漏或耗尽 socket。HTTP 原生 API 更适合边缘和无服务器运行时。
MQ 常见陷阱
用 MQ 掩盖慢代码
队列能把延迟移出请求路径，但不会让工作消失。要监控延迟、重试和消费者吞吐。
重复消息破坏副作用
支付、邮件、发票和通知都需要幂等键，因为重试和重新投递很正常。
积压会变成账单
消费者宕机会制造保留数据、网络用量、重试风暴和额度耗尽。
MQ 不是用户在线状态
在线用户、输入状态和实时协作，应该用 realtime/WebSocket 服务，而不是后端队列。
推荐 MQ 架构模式
Webhook -> 队列 -> Worker
快速接收、可靠入队、稍后处理。支付、GitHub 事件和第三方回调都适合这个模式。
函数生产者 + Upstash Kafka
边缘或无服务器函数通过 HTTP 发布事件，后端消费者处理分析、审计日志或异步任务。
IoT 设备 + MQTT Broker + 数据库
设备发布小消息，broker 路由 topic，下游服务持久化或响应数据流。
相关分类
消息队列常见问题
消息队列是做什么用的？+
它让系统一部分发布任务，另一部分稍后处理，从而提升可靠性、缓冲峰值并解耦服务。
MQ 和 WebSocket 有什么区别？+
MQ 通常是后台异步处理基础设施；WebSocket 是面向用户的实时连接，用于实时 UI 更新和协作。
无服务器应用应该用 TCP broker 吗？+
可以，但 HTTP 原生队列或流 API 通常更简单，因为无服务器运行时会创建许多短生命周期连接。
Redis 可以当队列用吗？+
小队列、Pub/Sub 和 Streams 可以。若需要更强持久性、重放、路由和死信行为，应使用专门 broker。
消息队列应该监控什么？+
监控积压大小、消费者延迟、重试次数、死信消息、发布失败、处理时间和额度使用。