不用hystrix-go因它保留java线程池模型，与go goroutine冲突，易误判且已停更六年；应选gobreaker——轻量、线程安全、原生支持context，被go-zero等主流框架验证。
为什么不用 hystrix-go 做熔断
hystrix-go 是 Java Hystrix 的移植，保留了命令包装、线程池隔离等重模型，在 Go 的 goroutine 场景下反而引入误判和额外开销：MaxConcurrentRequests 容易和 HTTP server 的连接池或 MaxHeaderBytes 冲突，导致请求卡在“等待执行”而非真实失败；SleepWindow 是固定时间，不感知下游是否真恢复；社区已基本转向 gobreaker 或 resilience-go——前者单文件、无依赖、状态清晰，后者支持 context 取消和指标导出。
rate.Limiter 怎么配才不打穿后端
rate.NewLimiter(rate.Every(100*time.Millisecond), 5) 表示「每 100ms 放一个 token，最多借 5 个」，即平均 10 QPS、突发容忍 5 请求。常见误配包括：
-
burst设得过大（比如 100），瞬时流量直接打穿下游 - 在 handler 里对每个请求调
limiter.Wait(ctx)后再进业务逻辑：若后端慢，令牌被长期占用，实际吞吐远低于配置值 - 全局共用一个
limiter实例，却按用户 ID 分 key 管理——粒度错位导致限流失效
正确姿势是把限流放在入口网关或中间件层，且只对明确的外部调用路径（如 /api/v1/payment）生效，排除 /health 和 /metrics 等内部接口。
熔断器和限流器怎么协同才不打架
二者不是并列开关，而是有先后顺序和状态反馈的配合关系：
- 必须先限流后熔断：限流控入口并发，熔断防下游雪崩；若顺序颠倒，熔断器可能因排队请求超时而误判失败
- 在限流逻辑中主动检查熔断器状态：
if cb.State() == gobreaker.StateOpen { return errors.New("service unavailable") }，避免令牌被无效占用 -
RequestVolumeThreshold建议设为略高于限流阈值（如限流 100 QPS，则设为 120），防止低流量下因采样不足误熔断 - 共享上下文关键指标：通过 Prometheus 暴露
requests_total{status="limited"}和circuit_state{service="user"}，用 Grafana 做联合看板
分布式场景下限流与熔断怎么同步状态
单机 rate.Limiter 和 gobreaker 天然不跨进程，生产环境必须解决状态一致性问题：
- 全局限流：用 Redis + Lua 实现滑动窗口，key 设计要带服务名+租户ID+时间戳，避免 key 冲突或过期混乱
- 全局熔断状态同步：不能靠本地内存，需将
State存入 Redis（如 hash 结构cb:payment-service:state），所有实例定期轮询或监听 Pub/Sub 更新 - 降级策略必须兜底：Redis 不可用时，自动 fallback 到本地
rate.Limiter和gobreaker，但需记录告警并限制 fallback 时长
真正稳定生产用的组合是 gobreaker + rate.Limiter，但分层部署、状态联动、可观测性补全是容易被忽略的复杂点——它们不写在代码里，却决定系统在流量高峰时是否真的扛得住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
