02｜接口总是被刷爆：Python 限流、熔断与降级实战

摘要

系统被流量打穿时，问题往往不在“并发太高”，而在“缺少保护层”。
这篇文章结合线上高峰场景，拆开讲清限流、熔断、降级三件事该怎么配合。
你可以把核心代码和策略直接放到 API 网关或服务入口做第一道防线。

SEO 摘要

基于 Python 讲解高并发场景下的限流、熔断与降级策略，覆盖令牌桶实现、熔断状态管理与兜底返回设计。适合后端工程师用于接口稳定性治理和突发流量止损。

目录

• 场景与目标
• 三层保护设计
• 关键实现代码
• 压测验证口径

场景与目标

目标不是“永不失败”，而是“失败可控”：

• 限流：防止瞬时流量打穿服务。
• 熔断：下游不稳定时快速止损。
• 降级：给用户可解释的兜底结果。

三层保护设计

1. 限流放最前。
2. 熔断保护下游依赖。
3. 兜底结果要可监控、可回溯。

关键实现代码

import time
from threading import Lock

class TokenBucket:
    def __init__(self, rate: float, capacity: int):
        self.rate = rate
        self.capacity = capacity
        self.tokens = capacity
        self.last = time.time()
        self.lock = Lock()

    def allow(self) -> bool:
        with self.lock:
            now = time.time()
            self.tokens = min(self.capacity, self.tokens + (now - self.last) * self.rate)
            self.last = now
            if self.tokens >= 1:
                self.tokens -= 1
                return True
            return False

class CircuitBreaker:
    def __init__(self, fail_threshold: int = 5, reset_timeout: int = 10):
        self.fail_threshold = fail_threshold
        self.reset_timeout = reset_timeout
        self.fail_count = 0
        self.open_until = 0.0

    def allow(self) -> bool:
        return time.time() >= self.open_until

    def on_success(self) -> None:
        self.fail_count = 0

    def on_fail(self) -> None:
        self.fail_count += 1
        if self.fail_count >= self.fail_threshold:
            self.open_until = time.time() + self.reset_timeout

bucket = TokenBucket(rate=80, capacity=160)
breaker = CircuitBreaker(fail_threshold=3, reset_timeout=8)

def fallback(uid: int) -> dict:
    return {"uid": uid, "profile": "系统繁忙，当前展示缓存数据"}

def get_profile(uid: int) -> dict:
    if not bucket.allow():
        return {"code": 429, "msg": "请求过快，请稍后再试"}
    if not breaker.allow():
        return {"code": 206, "data": fallback(uid)}
    try:
        raise RuntimeError("upstream timeout")
    except Exception:
        breaker.on_fail()
        return {"code": 206, "data": fallback(uid)}

压测验证口径

• 指标：错误率、P95 延迟、降级命中率。
• 目标：流量峰值时核心接口成功率保持 > 99%，并保证用户收到可解释结果。

指标对比示例

指标	改造前	改造后	结论
峰值时接口成功率	92.1%	99.2%	稳定性明显提升
P95 延迟	780ms	260ms	时延可控
下游超时传播比例	68%	19%	熔断有效止损

结尾互动问题

• 你的系统目前最先做的是限流、熔断还是降级？
• 你们是按接口维度还是按租户维度做限流？
• 当下游抖动时，你们有统一兜底策略吗？

高并发保护架构图

深度重构：为什么很多限流方案上线后仍然崩

很多系统加了限流后还是崩，常见原因是限流只做在单节点内存，没有全局视角。一旦流量被负载均衡打散，单机看起来没超阈值，整体却已经过载。生产实践里要根据系统形态选择策略：单体服务可先用本地令牌桶，多副本服务建议结合 Redis 或网关级限流，确保全局一致。

第二个问题是限流维度设计不合理。只按接口维度限流，会导致高价值用户被低价值请求挤占；只按用户维度限流，又可能无法抑制突发机器人流量。更稳妥的方式是做“多维复合限流”：接口维度兜底、租户维度保障公平、IP 维度防刷、用户等级维度保障核心客户体验。

第三个问题是熔断和重试冲突。很多团队把失败自动重试开太大，结果下游抖动时请求被放大，形成“重试风暴”。正确做法是：熔断开启时停止盲目重试，优先快速失败并走降级；熔断半开时仅放行少量探测流量，防止瞬间恢复流量再次压垮下游。

第四个问题是降级结果不可解释。用户看到“系统繁忙”并不会减少投诉，运营和客服也无法协同处理。建议降级响应中带上可理解提示、建议重试时间、是否已进入只读模式等信息。对 B 端系统，可在响应头附加 degrade=true 供前端展示降级提示。

参数调优思路（实战可用）

• 令牌桶速率：先按平峰 QPS 的 1.2-1.5 倍起步，再结合峰值回放调优。
• 桶容量：至少覆盖 1-3 秒突刺流量，过小会误伤正常请求。
• 熔断阈值：优先用时间窗口失败率，而不是绝对失败次数。
• 重置时间：根据下游恢复速度设置，避免过早半开造成抖动。
• 降级比例：核心功能优先保障，非核心功能可先降级。

故障演练模板（建议每月一次）

1. 模拟下游延迟升高至 2s，观察熔断是否触发。
2. 模拟 3 倍突发流量，验证限流命中率与误伤率。
3. 验证降级路径是否完整（前端提示、日志、监控、告警）。
4. 演练恢复过程，确认熔断半开不会引发二次雪崩。

案例复盘：一次活动峰值流量的止损过程

某电商活动开场后 3 分钟，支付查询接口 QPS 突然飙升到平时 4 倍。最初系统没有熔断，应用线程被下游超时拖死，错误率持续爬升。临时处理时先在网关层开启接口限流，把突刺流量挡在入口；随后打开熔断，快速切到降级数据，确保用户看到的是“稍后刷新”的可解释结果，而不是白屏报错。

稳定后回看链路，发现问题不是单一流量过高，而是“重试策略+下游抖动”叠加放大。重试间隔过短导致同一请求在下游抖动时被多次放大。整改后将重试改为指数退避，并把核心接口与非核心接口设置不同限流阈值。下一次活动中，峰值流量再出现时系统成功率保持在 99% 以上。

这次复盘说明：限流、熔断、降级不是三段独立配置，而是一套协同体系。入口挡压、链路止损、结果兜底必须同步设计。

常见问题 FAQ

Q1：限流阈值如何确定？
先以历史平峰流量为基线，按 1.2-1.5 倍起步，再通过压测校准。不要直接拍脑袋设置。

Q2：熔断打开后用户体验会不会变差？
短期会有感知，但比全站不可用更可控。降级响应要可解释，并尽量返回基础可用信息。

Q3：什么时候需要按租户限流？
当不同客户价值差异明显，且单一客户突发流量会挤占公共资源时，应优先引入租户维度限流。

实战结论

高并发治理不是“加一个组件”就结束，而是流量治理策略、业务优先级和运维流程的统一。限流负责把风险挡在入口，熔断负责阻断故障传播，降级负责保住用户体验底线。三者同时设计、同时验证，才能真正把系统从“脆弱可用”升级为“有损可用”。

版权声明

本文为原创技术实践文章，禁止未经授权的全文转载；引用请注明出处与本文链接。