一个代购站点在大促期间突然发现，自动采购模块的所有请求全部返回超时，后台日志刷了几百条连接错误。排查后发现，对1688 API的调用频率触发了对方的硬限流——连续大量失败后，系统还在不断重试，硬生生把一次临时限流演变成了持续十几分钟的服务中断。更糟糕的是，代购系统的PHP-FPM进程池几乎被这批等待超时的请求占满，其他正常的订单查询和物流追踪也跟着受影响。

代购系统对第三方API的依赖有多重，只要简单算一下就知道：1688的商品详情、订单提交、物流查询，淘宝的库存同步，EMS/DHL的轨迹追踪，PayPal/Stripe的支付接口——任何一个外部依赖出问题，都可能连锁影响到订单流转和客户体验。如果没有一套限流和熔断机制兜底，外部服务的抖动会直接传导到系统核心链路。

本文适合负责代购系统后端架构的开发者，前置知识要求对PHP、Redis和API网关有基本了解。如果只关注业务逻辑，可以跳过代码部分直接看限流策略和熔断状态机的设计思路。

令牌桶限流：让请求在安全速度内通过

限流方案的选择上，令牌桶比固定窗口和漏桶更适合代购场景。1688开放平台对不同认证等级的AppKey有明确的QPS限制，企业认证账号大概是每秒50次左右，个人开发者只有5到10次。固定窗口计数器会在一秒的开始集中放行所有请求，流量不均匀；漏桶强制匀速处理，突发请求会被排队延迟。令牌桶则在两者之间取得了平衡——以固定速率生成令牌，允许一定程度的突发，但总量受桶容量限制。

用Redis配合Lua脚本实现令牌桶，能保证分布式环境下的原子性。下面是一个简化版的令牌桶实现：

-- Redis Lua 令牌桶实现，保证原子性

local key = KEYS[1]

local rate = tonumber(ARGV[1])

local capacity = tonumber(ARGV[2])

local now = tonumber(ARGV[3])

local requested = tonumber(ARGV[4])



local bucket = redis.call('hmget', key, 'tokens', 'last_refill')

local tokens = tonumber(bucket[1]) or capacity

local last_refill = tonumber(bucket[2]) or now



local elapsed = math.max(0, now - last_refill)

local refill = math.floor(elapsed * rate / 1000)

tokens = math.min(capacity, tokens + refill)



if tokens >= requested then

    tokens = tokens - requested

    redis.call('hmset', key, 'tokens', tokens, 'last_refill', now)

    redis.call('expire', key, 60)

return 1

end

return 0

Lua脚本在Redis服务端原子执行，避免了多进程并发下的竞态问题。调用方在每次API请求前先尝试获取令牌，拿到令牌才发起真实请求，否则直接返回429并进入排队或降级逻辑。

在实际的代购系统部署中，Taocarts 的多租户架构为每个站点独立分配限流配置，不同代购团队的API调用配额互不影响，避免一个站点的高频请求挤占其他站点的令牌资源。

熔断器：别让一个故障的API拖垮整个系统

限流解决的是“别调用太快”的问题，熔断解决的是“对方已经挂了就别再调了”的问题。1688接口偶尔会因为签名升级、服务端故障或网络抖动导致大量请求失败。如果系统不做熔断处理，失败请求会持续堆积，不仅消耗系统自身的网络连接和进程资源，还可能因为反复重试触发对方更严厉的封禁。

熔断器的设计模仿的是电路断路器，核心状态有三个：关闭（正常调用）、打开（快速失败）、半开（尝试恢复）。在关闭状态下，系统正常调用外部API并统计失败次数；当连续失败次数达到阈值——比如10次——熔断器打开，后续请求不再真正调用API，直接返回降级结果；经过一段冷却时间后，熔断器进入半开状态，放行少量探测请求，成功则关闭熔断器恢复正常，失败则重新打开并重置冷却计时。

// 熔断器实现：三态切换 + 半开探测

class CircuitBreaker

{

    private const STATE_CLOSED = 'closed';

    private const STATE_OPEN = 'open';

    private const STATE_HALF_OPEN = 'half_open';



    public function call(string $api, callable $request): mixed

    {

        $state = Redis::hget('cb:state', $api) ?: self::STATE_CLOSED;

        $failCount = (int)Redis::hget('cb:fail', $api);



        if ($state === self::STATE_OPEN) {

            if (time() - (int)Redis::hget('cb:open_at', $api) < 30) {

                throw new \RuntimeException("熔断器已打开，请求快速失败");

            }

            Redis::hset('cb:state', $api, self::STATE_HALF_OPEN);

            $state = self::STATE_HALF_OPEN;

        }



        try {

            $result = $request();

            Redis::hset('cb:state', $api, self::STATE_CLOSED);

            Redis::hdel('cb:fail', $api);

            return $result;

        } catch (\Exception $e) {

            $failCount = Redis::hincrby('cb:fail', $api, 1);

            if ($failCount >= 10) {

                Redis::hmset('cb:state', $api, self::STATE_OPEN, 'cb:open_at', $api, time());

            }

            throw $e;

        }

    }

}

熔断器的配置需要根据被调用方的特性调整。1688这种QPS硬限制的API，连续失败阈值可以设低一些——比如5次——因为对方大概率真的出问题了。物流查询这类接口偶尔超时不算异常，失败阈值可以放宽到15到20次。冷却时间一般设30秒到两分钟，太短来不及恢复，太长影响业务。

组合效果与配置建议

令牌桶和熔断器组合后的效果，可以从两个场景对比看出差异。一个未做任何保护的代购系统，在1688 API限流后持续重试，进程池被占满的时间大概在几十秒内，波及面覆盖全部客户请求。加上令牌桶限制调用速率后，超限请求在入口就被拦截，不会穿透到实际调用层。加上熔断器后，连续失败一旦触发阈值，后续请求直接快速失败，等待恢复期间释放的进程资源可以正常服务其他业务模块。重试机制则负责处理临时失败——比如网络抖动导致的偶发超时——指数退避重试可以把这类临时失败的成功率从八成多提升到接近百分之百。

限流和熔断的参数没有统一标准，取决于代购系统的日均调用量和被调用API的限流策略。一个起步阶段的代购站点，1688 API的企业版调用量大概在每天5000次上下，令牌生成速率设为每秒4到5次、桶容量设为10就足够。物流查询API的调用频次较低，令牌速率可以设到每秒2次。关键是给每个外部依赖单独配置限流参数，避免“一刀切”导致高频接口被误限或低频接口被浪费。

花一周把这些保护机制搭好，之后每天省下的排查和修复时间远不止两小时。好的订单管理，不是功能列表有多长，而是关键时刻不掉链子——外部API抖动了系统能自己稳住，这才是熔断机制在代购场景下真正的价值。