ThinkPHP Redis 队列消息丢失怎么处理修复方案-ThinkPHP-PHP中文网

redis队列消息丢失主因是配置错误导致降级为sync同步模式，或消费端未调用$job->delete()致重复执行；须确保queue配置正确、启用brpoplpush原子操作、设置合理expire/retry_after、定时清理pending list。

thinkphp redis 队列消息丢失怎么处理修复方案

确认你真正在用 Redis 队列，而不是 sync 同步模式

很多“消息丢失”根本不是丢，是压根没进队列——default 没设成 'redis'，或 connections.redis.type 写成 'Redis'、'redis-driver'，ThinkPHP 就会静默 fallback 到 sync 模式：任务在当前请求里同步执行，一报错就消失，毫无重试可言。

检查方式很简单：php think queue:listen --queue=default 启动后，立刻去 Redis 里看有没有 queues:default 这个 key：redis-cli KEYS "queues:*"。没有？说明配置没生效。

config/queue.php 中 default 必须是小写字符串 'redis'
connections.redis.type 也必须是 'redis'，不能带空格或大小写混用
TP6 路径是 config/queue.php，TP5 是 application/extra/queue.php，路径错等于白配

投递成功但消费端不 delete，消息反复执行或卡死

ThinkPHP 的 Redis 驱动不会自动清理已消费任务。只要 $job->delete() 没被调用，这条消息就会一直留在 queues:default list 里，下次 work 或 listen 轮到它，又会取出来执行一遍——看起来像“重复消费”，实则是“从未真正完成”。更糟的是，如果失败逻辑里只 return 不 release，任务就彻底丢了，连进 failed 表的机会都没有。

redis-tools

按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。

下载

所有成功路径结尾必须显式调用 $job->delete()
失败时不要直接 return，要用 $job->release($delay) 延迟重试（比如 $job->release(60)）
若配了 failed.type => 'database'，记得建好 failed_jobs 表，否则失败任务无处可存

BRPOPLPUSH 没启用，或 Pending List 积压无人管

ThinkPHP 默认用 RPOP + LPUSH 模拟“取出+暂存”，但这不是原子操作——中间存在竞态窗口：RPOP 取出消息后、LPUSH 写入 pending 前，进程崩溃，消息就永久丢失。官方 think-queue 并不默认启用 BRPOPLPUSH，得靠你自己补。

即使你手动改用 BRPOPLPUSH，Pending List（如 queues:default:reserved）本身没有 TTL，也不自动清理。消费者处理完忘了 LREM，或 ACK 步骤抛异常没兜住，这个 list 就会越攒越多，最后吃光内存。

别依赖客户端轮询模拟，直接在 Redis 层用 BRPOPLPUSH source dest timeout 原子转移
Pending List 的 key 名要有业务隔离性，比如 queues:default:pending:{worker_id}，避免多个 worker 互相污染
必须加定时任务或看门狗：扫描 queues:default:reserved 中 score 小于当前时间戳的项，ZRANGEBYSCORE + ZREM 清理超时未确认任务（建议超时设为 retry_after + 30 秒）

expire 和 retry_after 配反，导致任务被误删或无限重试

expire 是任务在队列里的最长存活时间（秒），超时后会被 Redis 自动丢弃；retry_after 是任务被取出后，多久没调 delete 就算失败、自动放回队列重试。这两个值一旦设反或差距太小，就会出问题：比如 retry_after = 30，expire = 20，任务还没开始处理就被删了；又或者 retry_after 远小于实际处理耗时，任务刚取出来就立刻重试，形成雪崩。