PHP无原生Hystrix，可用Guzzle+状态机模拟熔断：基于共享存储（APCu/Redis）统计请求成功率，达阈值后触发熔断并执行本地fallback，需合理设置超时分层、key命名与sleep窗口。
PHP 没有原生 Hystrix，但可以用 guzzlehttp/guzzle + 状态机模拟熔断
PHP 本身不提供类似 Java Hystrix 那样的声明式熔断框架，强行套用“降级/隔离/熔断”概念容易误判失败类型。真正能落地的，是基于 HTTP 客户端（比如 GuzzleHttp\Client）封装一层带状态跟踪的请求代理。
常见错误现象：curl_exec(): Could not resolve host 或 Connection refused 被当成业务异常吞掉，导致下游持续重试、线程耗尽；或者短时间大量超时，但 PHP 进程没感知到“该停了”。
- 核心思路：用一个共享存储（如
apcu或 Redis）记录服务最近 N 次调用的成功/失败/超时次数 - 触发熔断条件不是“一次失败”，而是“过去 60 秒内失败率 > 50% 且总请求数 ≥ 20”这类可配置阈值
- 熔断后所有请求直接走
fallback回调，不发网络请求，避免雪崩扩散 - 必须设置
sleepWindowInMilliseconds类似机制——比如熔断 30 秒后自动进入半开状态，只放行 1 个试探请求
用 apcu 实现轻量熔断器要注意 key 冲突和过期策略
apcu 是最常用的进程内缓存方案，但它的 key 是全局共享的，不同服务如果都用 "circuit_breaker_user_service" 这种简单命名，极易覆盖彼此状态。
- key 必须带唯一标识：建议组合为
"cb_".md5($serviceName."_".$thresholdConfig)，避免手动拼接出错 -
apcu_store()的过期时间不能设太长——熔断状态本身是临时决策，设成 60 秒比永不过期更安全 - 注意 PHP-FPM 子进程隔离：
apcu在每个 worker 进程里独立，所以严格来说它只是“单进程熔断”，要跨进程需换redis - 若用
redis，别用INCR单命令统计——得用 Lua 脚本保证原子性更新计数+时间窗口
超时设置必须分层：DNS 解析、连接、读取三者不能共用一个 timeout
很多 PHP 开发者只设 timeout => 5，以为就是 5 秒总耗时，其实 Guzzle 默认把这 5 秒全分配给“读取响应体”，DNS 和 TCP 建连可能额外卡住 10 秒，照样拖垮整个请求链。
立即学习“PHP免费学习笔记（深入）”；
- 正确做法是显式拆分：
connect_timeout => 1、timeout => 3、再配合dns_cache_timeout => 30 - 熔断器判断“失败”时，只应计入连接失败和读取超时，DNS 失败通常意味着基础设施问题，不该计入熔断统计（否则一整个机房 DNS 故障会误触发全站熔断）
- 使用
curl_setopt($ch, CURLOPT_NOSIGNAL, true)防止 PHP 信号中断干扰超时逻辑（尤其在 alpine 小镜像里常见）
fallback 函数不能依赖外部服务，否则变成“熔断嵌套熔断”
写 fallback 最容易犯的错，是让它再去查 Redis、调另一个 API 或渲染模板——一旦 fallback 也慢或挂了，上层熔断器就失去意义，反而加重负载。
- fallback 应该是纯内存计算：返回硬编码默认值、从本地 JSON 文件读缓存、或用上一次成功结果（需加
apcu时间戳校验） - 不要在 fallback 里记录日志到远程 ELK——日志写本地文件或 stdout 即可，避免 fallback 成为新瓶颈
- 如果业务允许，fallback 可直接抛出
new \RuntimeException("service unavailable")，由上层统一兜底，比返回假数据更可控
熔断真正的复杂点不在代码实现，而在阈值怎么定：太敏感，正常抖动就熔；太迟钝，雪崩已经发生才反应。上线前必须用 ab 或 wrk 模拟真实失败率，而不是靠拍脑袋设 50%。
