PHP生产环境熔断需用Redis+Lua或APCu+原子操作实现滑动窗口，因多进程无状态特性使数组/文件无法跨进程同步且不能自动淘汰过期项；Redis推荐ZSET+Lua原子清理与统计，APCu仅限单进程且须手动时间过滤与防GC丢失；失败率判断须满足最小请求数、最小失败数及阈值三重条件。
PHP 没有原生滑动窗口熔断支持，GuzzleHttp\Client 本身也不带失败率统计能力。真正在生产环境跑得稳的方案，必须用共享存储（Redis 或 APCu）+ Lua 脚本（Redis 场景）或原子操作（APCu 场景）来维护一个时间窗口内的请求/失败计数，否则“过去 60 秒失败率 > 50%”这种条件根本不可靠。
滑动窗口为什么不能用简单数组或文件存？
PHP 是无状态、多进程模型，$_SERVER['REQUEST_TIME_FLOAT'] 级别的时间戳在不同 FPM worker 里互不感知；用普通数组存最近 100 次调用记录，既无法跨进程同步，也无法自动淘汰过期项。常见错误现象是：明明服务已恢复，熔断器还在持续拒绝请求——因为旧失败记录没被清理，或者新请求压根没写进统计池。
关键点：
- 滑动窗口必须绑定时间维度，不是“最近 N 次”，而是“最近 T 秒内”
- 每次请求进来，要同时做两件事：写入本次结果（成功/失败）、剔除窗口外的旧记录
-
APCu无法保证跨进程一致性，apcu_store('cb_user', $data, 60)只在当前 worker 有效，FPM 多进程下等同于“每个进程自己熔断自己” -
Redis是首选，但别用INCR+EXPIRE组合——网络往返间隙会导致计数错乱，必须用EVAL执行 Lua 脚本完成原子更新
Redis 滑动窗口 Lua 脚本怎么写才安全？
核心逻辑是：以 cb:{service_name} 为 key，用 Redis 的 ZSET 存时间戳+结果（1=成功，0=失败），score 为毫秒时间戳。每次请求执行 Lua 脚本，自动清理过期成员、插入新记录、计算当前窗口内失败率。
立即学习“PHP免费学习笔记（深入）”；
示例脚本（需通过 $redis->eval($script, 1, 'cb:user_service') 调用）：
local key = KEYS[1]
local now = tonumber(ARGV[1])
local window_ms = tonumber(ARGV[2]) -- e.g. 60000
local is_success = tonumber(ARGV[3]) -- 1 or 0
<p>-- 清理窗口外数据
redis.call('ZREMRANGEBYSCORE', key, 0, now - window_ms)</p><p>-- 插入新记录
redis.call('ZADD', key, now, is_success)</p><p>-- 统计总数和失败数
local total = redis.call('ZCARD', key)
local failed = redis.call('ZCOUNT', key, 0, 0)</p><p>return {total, failed}调用时传参：microtime(true) * 1000、窗口毫秒数（如 60000）、是否成功（0 或 1）。返回数组第一项是总请求数，第二项是失败数，PHP 层据此判断是否触发熔断。
APCu 实现滑动窗口的底线要求
如果只能用 APCu（比如无 Redis 环境），必须接受“单进程熔断”的事实，并规避 key 冲突与过期陷阱：
- key 必须唯一且带哈希：用
'cb_'.md5($serviceName.$windowMs.$threshold)，别用硬编码字符串 - 值结构必须包含时间戳数组：例如
['ts' => [1746048600.123, 1746048601.456], 'result' => [1,0]]，每次写入前手动array_filter掉time() - $windowS之前的项 -
apcu_store()的 TTL 必须设为略大于窗口时间（如窗口 60 秒，TTL 设 70），防止因 APCu GC 导致状态丢失 - 不要依赖
apcu_inc()做计数——它不带时间上下文，无法区分新旧请求
失败率阈值判断时最容易漏掉的边界
直接用 $failed / $total > 0.5 是错的。真实场景中，刚启动的服务可能只有 2 次请求，1 次失败就触发熔断，太敏感；而高流量服务 1 秒 1000 次请求，失败率 0.1% 也可能代表 1 秒挂了 1 次，但总次数太大导致分母失真。
正确做法是加双条件：
- 总请求数 ≥ 最小采样量（如
20），避免冷启动误判 - 失败率 ≥ 阈值（如
0.5），且失败数 ≥ 最小失败数（如10），防止单次抖动放大 - 只计入连接失败（
Connection refused、curl_error 7）和读取超时（curl_error 28），DNS 解析失败（curl_error 6）应跳过统计——那是基础设施问题，不该拖垮整个熔断逻辑
滑动窗口本身不难实现，难的是让失败率统计真正反映服务健康度，而不是被网络抖动、进程隔离或脚本竞态带偏。上线前务必用 ab 或 wrk 模拟连续失败+间歇恢复，观察状态切换是否及时、半开试探是否只放行 1 个请求、窗口滚动是否准确剔除旧数据。
