hyperf异步队列生产环境必须配置加固以应对redis宕机等故障：①channel需带命名空间前缀；②retry_seconds设为60秒；③handle_timeout设为300秒；投递层须同步校验llen或启用事务；消费层禁用自动ack、手动控制消息生命周期并加心跳检测；运维层启用aof everysec、定时备份rdb+元信息、logstash实时归档aof操作。
Hyperf异步队列在生产环境必须扛住Redis宕机、进程崩溃、网络闪断等真实故障，否则订单通知发不出、邮件没发送、风控告警延迟——这些都不是“可能”，而是已经发生的线上事故。
配置层加固：让消息进得去、存得住
打开 config/autoload/async_queue.php，确认以下三项已显式设置：
① 【'channel' => 'async-queue:default'】 —— 必须带命名空间前缀，避免与其他业务队列混用导致消费错乱；
② 【'retry_seconds' => 60】 —— 将默认5秒重试拉长到60秒，给Redis恢复留出缓冲窗口；
③ 【'handle_timeout' => 300】 —— 消费逻辑超时设为5分钟，防止因数据库慢查询或HTTP阻塞导致任务被强制终止丢弃。
若使用多队列，每个队列的 'processes' => 0 必须保持为0，否则 ConsumerProcess 启动时会直接 fork 子进程抢占队列，造成消息被跳过消费。
投递层加固：写入失败立刻感知
方法一：同步校验 Redis 写入结果
在 Job 投递后，立即执行 Redis::command('LLEN', ['async-queue:default'])，返回值为0说明消息根本没进队列——此时必须抛异常并触发告警，不能静默吞掉错误。
方法二：启用 Redis 事务包装投递
改用 Redis::transaction(function ($redis) use ($job) { $redis->rpush('async-queue:default', json_encode($job)); $redis->incr('async-queue:push:counter'); });，确保 push 和计数原子性，后续可通过 counter 与 LLEN 对比发现丢包。
消费层加固：不成功就不确认
第一步：禁用自动 ACK
在 config/autoload/processes.php 中注册 ConsumerProcess 时，【不得使用 @Process 注解自动启动】，必须手写继承类并重写 handle() 方法。
第二步：手动控制消息生命周期
在 Job 的 handle() 方法末尾添加 if ($this->isSuccess()) { $this->delete(); } else { $this->release(60); } —— 成功才删消息，失败则释放回队列并延迟60秒再投，避免瞬时失败反复刷屏。
第三步：兜底心跳检测
在 handle() 开头插入 if (time() - $this->createdAt > 3600) { $this->delete(); return; }，超过1小时的老消息直接丢弃，防止死信堆积压垮Redis内存。
运维层加固：双通道+离线备份
启用 Redis AOF 持久化（appendonly yes），并配置 appendfsync everysec —— 这是唯一能保证断电不丢数据的方案，RDB 快照间隔太长，无法满足秒级可靠性要求。
每5分钟执行一次 php bin/hyperf.php redis:backup 命令，该命令会：
• 调用 BGSAVE 生成 RDB 快照
• 执行 INFO replication 记录主从偏移
• 将 dump.rdb + 元信息打包上传至 OSS
【备份路径必须包含时间戳和 Redis 实例ID，否则多实例备份文件会相互覆盖】
同时部署独立的 Logstash 服务，监听 Redis AOF 文件变更，实时将每条 *PUSH 操作写入 Elasticsearch 归档库——这是最后一条防线，当 Redis 数据彻底损坏时，可从 ES 中提取原始消息重放。
