PHP分布式任务框架的降级需覆盖调度、执行、回写三层协同，而非单点try-catch；任务投递失败应本地落库重试，执行时按关键性分级降级，结果回写须保障最终一致性。
PHP分布式任务框架里，服务降级不是“加个try-catch就完事”，而是要分清「谁在调用」「谁可能挂」「挂了之后谁来兜底」「兜底值能不能被业务接受」。真正在生产扛压的方案，核心落在任务调度层、执行层、结果回写三个环节的协同降级，而不是只盯着某一个函数改。
任务投递失败时怎么避免丢任务
很多团队用 RabbitMQ 或 Redis 做任务队列，但没意识到：客户端连不上 Broker 时，publish() 抛异常 ≠ 任务必须失败。这时候该走本地延迟重试 + 降级落库，而不是直接返回错误。
- 投递前先 ping 队列服务（比如
$rabbit->getConnection()->isConnected()），失败则写入本地task_fallback_log表，带status = 'pending_local'和retry_count = 0 - 配一个 Swoole 定时任务每 30 秒扫一次该表，对
retry_count < 3的记录尝试重投；超限则标记为failed并触发告警 - 别用文件存 fallback 任务——并发写会冲突，也难做幂等和清理
- 如果用
Hyperf\Task，注意它默认不支持断线自动 fallback，得自己 wrapTaskExecutor类，在execute()里捕获ConnectionException
Worker 执行时外部依赖不可用怎么办
Worker 拿到任务后，常要查 Redis、调支付接口、写 ES。这些环节挂了，不能让整个任务卡死或无限重试——得按字段/动作分级降级。
- 对非关键字段（如
user_tags），用缓存健康标记（think\Cache::tag('redis_status')->get('healthy')）判断，假阴性概率高就加双检：先ping再get - 对关键动作（如扣库存），不允许降级，必须抛异常并进死信队列；但要在异常消息里带上原始参数和当前兜底策略开关状态，方便人工介入
- 别在
beforeHandle事件里统一设兜底值——不同任务类型逻辑差异大，容易误覆盖。推荐在具体handle()方法开头做检查：if (!$this->paymentClient->isHealthy()) { $this->fallbackPayment = Config::get('task.payment_fallback'); } - 所有兜底值必须和原字段类型强一致：数据库是
TINYINT，就传0不传'0'；是 JSON 字段，就传json_encode([])而不是空字符串
任务结果写回失败导致状态不一致
任务执行完了，但更新 MySQL 订单状态或写入 ES 失败，是最容易引发资损的场景。此时不能靠“下次重试”来补，得有明确的最终一致性保障机制。
立即学习“PHP免费学习笔记（深入）”；
- 写回操作必须包装成独立事务块，且用
DB::transaction()包裹，失败立即 rollback，不污染主流程 - 对写 MySQL 失败的任务，记入
task_result_pending表，并带唯一task_id + attempt_id索引，防重复插入 - 用独立的补偿进程（非 Worker）定时扫描该表，对超时未确认的任务发起幂等回查（比如调支付网关查订单状态），再决定是重写还是标记为终态异常
- ES 写失败可降级为写本地
search_fallback表，搜索接口查 ES 无结果时自动 fallback 到该表——但要注意字段映射不能错，比如 ES 的keyword类型对应 MySQL 的VARCHAR(255)
真正的难点不在代码怎么写，而在于每个降级点都要回答清楚：这个值/状态/动作一旦错了，业务上能不能接受？能接受几秒？能接受多少比例？没有这个判断，所有兜底都是空中楼阁。
