队列削峰通过“先收后处理”缓解 MySQL 写入压力，将瞬时高并发请求缓冲为稳定低频写入。典型方案包括 RabbitMQ、Kafka 和 Redis List，需配套校验、幂等、DLQ 及监控机制。
用队列削峰解决 MySQL 写入压力，核心是把实时强依赖的写操作变成“先收后处理”，让高 并发请求 不直接打到数据库，而是进队列排队，再由消费者异步、可控地落库。
为什么 需要队列削峰
秒杀、抢券、日志上报等场景常出现瞬时大量写请求。MySQL 在高并发 INSERT/UPDATE 下容易出现连接耗尽、锁等待加剧、主从延迟飙升，甚至主库夯住。队列作为缓冲层，能平滑流量波峰，把突发的 10000 QPS 降为稳定的 500 QPS 持续写入，给数据库留出喘息空间。
典型技术组合选型
常见轻量可靠方案有三种搭配：
- RabbitMQ + Spring Boot Listener：适合事务要求高、需确认机制的场景，支持消息持久化和 ACK 重试；
- Kafka + Kafka Consumer：吞吐高、分区有序，适合日志类或允许少量乱序的业务，注意 offset 提交策略；
- Redis List + Lua + Worker 进程：极简部署，用 LPUSH + BRPOP 实现 FIFO 队列，适合中小流量且对消息可靠性要求适中的系统。
关键设计细节不能漏
光加队列不够，必须配套控制逻辑：
- 写入前做简单校验：比如用户 ID 是否合法、活动是否已结束，避免无效消息占满队列；
- 消费者要幂等：MySQL 执行前查主键 / 唯一索引是否存在，或用 REPLACE INTO / INSERT … ON DUPLICATE KEY UPDATE；
- 失败消息要进死信队列（DLQ）：连续三次消费失败就隔离，人工介入排查，防止阻塞后续消息；
- 监控队列积压水位：比如 Redis LLEN 或 Kafka lag > 1000 就告警，说明消费者处理不过来，需扩容或优化 SQL。
一个最小可行示例（Redis + PHP）
用户下单请求过来，不直接 INSERT 订单表，而是：
→ PHP 接口接收参数 → 校验库存和用户状态 → 构造订单 JSON → RPUSH 到 redis 队列 order_queue → 返回“已受理”
后台起一个常驻脚本（如 supervisor 管理的 worker.php）：
→ BLPOP order_queue 0 → json_decode → 开启事务 → INSERT 订单主表 + 明细表 → COMMIT → 循环
这样 前端 响应快，数据库压力可控，异常时只影响单条消息，不影响整体链路。
