17370845950

PHP 8.4 不支持 ext-redis 原生队列语义，需用 lPush/brPop 手动实现 FIFO 队列，或选用 symfony/messenger 等成熟组件；注意 JSON 编码、超时设置、死信处理及 Redis 内存与幂等控制。

PHP 8.4 中不能直接用 ext-redis 原生支持队列语义

PHP 本身没有内置队列任务调度能力，ext-redis（哪怕在 PHP 8.4）也只是提供 Redis 协议的客户端封装，不带 enqueue、dequeue 等高级队列抽象。所谓“Redis 队列”，本质是用 LPUSH/RPOP 或 BRPOP 等原子命令模拟 FIFO 行为，需自行设计结构和容错逻辑。

用 Redis::lPush() 和 Redis::brPop() 实现基础任务入队与阻塞消费

这是最轻量、兼容性最好（PHP 7.4+ / 8.4 均可用）的方式，适合低并发、无严格可靠性要求的场景。注意：PHP 8.4 默认启用严格类型检查，调用前确保连接已初始化且未关闭。

• lPush() 入队：任务数据建议 JSON 编码，避免二进制或特殊字符破坏结构
• brPop() 出队：必须设超时（如 0 表示永久阻塞，5 表示 5 秒），否则会立即返回 null 导致忙轮询
• 消费失败时，别直接丢弃——应记录日志并考虑重推回队列或转入死信列表（如 LPUSH queue:dlq ...）

$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

// 入队：发送一个简单任务
$job = json_encode(['type' => 'send_email', 'to' => 'user@example.com']);
$redis->lPush('queue:jobs', $job);

// 消费：阻塞等待最多 5 秒
$result = $redis->brPop(['queue:jobs'], 5);
if ($result && count($result) === 2) {
    $payload = json_decode($result[1], true);
    // 执行任务逻辑...
}

PHP 8.4 下推荐用 php-enqueue 或 symfony/messenger 替代手写

手动实现易出错：缺乏重试策略、任务超时控制、并发竞争处理、监控埋点等。PHP 8.4 对协程（ext-uv）、FFI 支持增强，但主流队列库尚未全面适配其新特性；此时更稳妥的选择是成熟组件：

• symfony/messenger v7+ 已声明支持 PHP 8.4，可通过 RedisTransport 直接对接 Redis，自动处理序列化、ACK、重试、延迟队列
• php-enqueue（已归档）仍有项目在用，但新项目不建议；其 redis 包依赖旧版 predis/predis，与 PHP 8.4 的 strict type 要求偶有冲突
• 若用 ext-redis，需确认 Redis::setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_PHP) 未被启用——它会导致 JSON 数据被二次序列化，消费端解码失败

容易被忽略的 Redis 队列边界问题

很多人只关注“能跑”，却在压测或上线后遇到诡异故障：

• Redis 内存爆满：未设置 maxmemory 和淘汰策略（如 allkeys-lru），导致 LPUSH 失败却不报错（返回 0）
• 消费者崩溃导致任务丢失：没用 BRPOP + LREM 组合实现可靠出队，而是 RPOP 后再处理——中间 crash 就永远丢失
• 多实例消费同一队列时出现重复执行：Redis 无内建锁机制，需靠 SET job:123 lock EX 30 NX 这类方式做幂等控制，不能只靠队列名隔离

真正稳定的队列不是“写完就能用”，而是得覆盖失败重试、进度追踪、积压告警这些环节——PHP 8.4 只是运行环境，不是队列解决方案。