主从延迟熔断需主动监控seconds_behind_master并注入gobreaker：周期采样延迟值，readytotrip结合延迟阈值与失败次数判断，降级分层处理，避免误判null/负数，校验业务时间窗口确保数据可信。
主从延迟导致读请求拿到脏数据或空结果，不是数据库连接问题，也不是 SQL 报错，gobreaker 默认的失败统计机制完全捕获不到——必须把“延迟感知”显式注入熔断逻辑。
如何用 SHOW SLAVE STATUS + Seconds_Behind_Master 触发熔断
MySQL 主从延迟不能靠超时或错误码判断，得主动查从库状态。关键点是：不能每次读都去执行 SHOW SLAVE STATUS（开销大），而应周期性采样 + 缓存结果，并在熔断器中引用该延迟值。
- 单独起一个 goroutine，每 2–5 秒执行一次
SHOW SLAVE STATUS，提取Seconds_Behind_Master字段，写入内存变量（如atomic.Value或带锁的 struct） - 在
ReadyToTrip函数里读这个变量，比如：return delaySecs > 30 && counts.ConsecutiveFailures > 2，即“延迟超 30 秒且最近有 2 次读失败”才熔断 - 注意：
Seconds_Behind_Master为NULL（IO/SQL 线程停止）或负数（从库快于主库）需单独处理，避免误判
gobreaker 的 ReadyToTrip 必须结合业务语义重写
默认只看 ConsecutiveFailures，但主从延迟场景下，“失败”往往不是 error，而是返回了过期数据（比如用户刚下单，读从库却查不到订单）。这时得在业务层埋点判断是否属于“延迟敏感型失败”。
- 对关键读操作（如查订单、查余额），封装一层校验逻辑：
if order.CreatedAt.After(time.Now().Add(-5 * time.Second)) == false，则视为“逻辑失败” - 把这个判断结果传给
cb.OnError()或直接在Execute包裹函数里return nil, errors.New("stale_read") -
ReadyToTrip改成检查counts.TotalFailures而非仅ConsecutiveFailures，因为延迟可能持续数十秒，中间夹杂成功请求会重置连续计数
熔断后降级路径必须绕过从库，但不能全切主库
直接把所有读请求打到主库会压垮写链路，降级策略要分层：
- 一级降级：返回本地缓存（如
bigcache中的最近 10 分钟订单摘要），适用于“最终一致性可接受”的场景 - 二级降级：异步触发
SELECT ... FOR UPDATE到主库查最新态，同时立即返回“数据同步中”，避免用户等待 - 绝对禁止：在
Open状态下仍往从库发读请求——哪怕加了read_timeout=100ms，也会放大延迟抖动，让熔断器更难恢复
Timeout 和 Interval 参数容易配反，导致半开失效
很多团队把 Timeout 设成 5 秒、Interval 设成 60 秒，结果熔断器永远卡在 Open 状态不试探——因为 Interval 控制的是“失败计数器重置周期”，而 Timeout 才决定多久后进入 Half-Open。
- 正确配法：
Timeout: 30 * time.Second（30 秒后允许试探），Interval: 0（不重置计数器，让历史失败持续影响判断） - 如果设
Interval > 0（比如 60 秒），而Timeout小于它（比如 10 秒），会出现“刚进Half-Open，计数器就清零”，导致试探请求失败后无法准确累积新失败数 - 验证方式：监听
OnStateChange回调，打印状态切换日志，确认Open → Half-Open是否如期发生
真正棘手的不是熔断本身，而是如何定义“这次读是不是因延迟而不可信”——这需要你深入业务时间窗口（比如支付订单必须 ReadyToTrip 和降级分支里。没有通用阈值，只有贴着业务节奏调出来的参数。
