缓存击穿本身不直接影响消息队列，但会因拖垮共用数据库间接导致消费者卡顿、积压上升、元数据操作失败等连锁问题。

不会直接产生影响，但可能间接拖垮消息队列的消费能力。

缓存击穿本身不触碰消息队列

缓存击穿是读场景问题：请求打到 Redis → 缓存 miss → 全部涌向数据库。整个链路不涉及消息队列的生产或消费逻辑。LPUSH、BRPOP、XADD 这些操作不会因 GET 缓存失效而自动触发。消息队列是否被调用，完全取决于业务代码是否主动把它写进读路径里——而标准的 Cache-Aside 模式里，它根本不出现。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

但数据库被击穿后，消息队列可能“被连累”

当缓存击穿导致数据库 CPU 打满、连接池耗尽、慢查询堆积时，依赖数据库的下游组件会集体卡顿。如果消息队列的消费者（比如订单履约服务）需要频繁查库做状态校验、幂等判断或路由分发，就会出现：

• 消费者处理一条消息耗时从 50ms 拉长到 2s+，积压迅速上升
• BRPOP 等待超时后重试，重复拉取同一批消息，加重 DB 压力
• 事务型消费者（如基于本地消息表的方案）在 INSERT 消息记录时阻塞，导致生产端写入失败
• 死信队列被填满，因为消费者根本来不及 ACK

容易被忽略的关键点：消息队列和缓存共用同一套 DB 资源

很多团队把消息元数据（如延迟队列的定时任务表、死信追踪表、消费者 offset 记录）和业务主库放在同一个 MySQL 实例上。缓存击穿打崩的是这个实例，不是 Redis。此时即使消息队列服务本身没出错，它的元数据读写也全挂了——delay_queue_task 表查不出来，consumer_offset 更新不了，整个队列就“假死”。这种耦合比代码逻辑耦合更隐蔽，也更难隔离。