SMARTPAY

菲律宾支付网关API限流与并发处理:高并发下单怎么设计

促销日订单量冲高,为什么网关突然"拦"你

做菲律宾本地业务这几年,我们团队踩过不止一次"大促当天下单量短时间内明显上涨,结果支付接口大面积报错"的坑。复盘下来,根本原因往往不是网关故障,而是我们自己的系统在短时间内把请求砸得太密,触发了网关侧的限流(rate limiting)。多数正规支付网关都会设限流规则,一方面保护自身系统稳定,另一方面也是风控的一部分——短时间内异常密集的调用频次,本身就是可疑交易的典型特征之一。

这篇文章想聊清楚一件事:接口限流不是网关"卡你",而是系统设计阶段就必须纳入的硬约束。怎么识别网关用的是哪种限流策略、商户侧怎么配合重试和排队、以及高并发下怎么守住订单状态不乱,是技术负责人接入任何支付 API之前就该想清楚的问题。

网关常见的三种限流策略,你的系统要适配哪一种

不同网关的限流实现方式不完全一样,但万变不离其宗,常见的是这几类。

固定窗口(Fixed Window):把时间切成固定长度的区间,比如每分钟一个窗口,窗口内允许通过的请求数有上限,超过就拒绝,窗口一过计数清零。实现简单,但窗口边界容易出现"临界突刺"——窗口切换的瞬间,前一个窗口尾部和下一个窗口头部叠加,短时间内实际通过的请求量会明显超过设定的平均水平。

令牌桶(Token Bucket):系统按固定速率往桶里放令牌,每次请求要消耗一个令牌,桶满则不再增加,桶空则请求被拒绝或排队。令牌桶允许一定程度的突发流量(只要桶里还有存量令牌),同时长期速率仍受控,是目前多数支付网关和网关前置的 API Gateway 用得最多的方案。

漏桶(Leaky Bucket):请求先进桶,再以固定速率"漏"出去处理,桶满则拒绝新请求。漏桶的输出速率是恒定的,不会因为短时间堆积请求而加速处理,更适合要求下游处理节奏绝对平稳的场景。

我们在对接时,一般建议先问清楚对方网关用的是哪一种、限额阈值是多少、超限返回什么状态码(常见是 HTTP 429),这几个参数直接决定商户侧重试策略怎么设计。

限流策略核心原理突发流量容忍度实现复杂度典型场景
固定窗口固定时间区间内限定请求数,到点清零低,窗口切换处易突刺低简单接口的基础防护
滑动窗口按滚动时间片累计请求数,无明显边界效应中中对精度要求较高的网关前置层
令牌桶按速率发放令牌,消耗令牌放行请求较高,桶内存量可应对短时突发中支付网关 API、订单提交接口
漏桶请求先排队,按固定速率匀速处理低,输出速率恒定中高要求下游处理节奏平稳的清算/批处理

商户侧要不要自己也做一层限流

很多团队接入支付网关时只关心"网关限不限我",却忽略了商户系统自己也该有一层主动限流,原因有两个。第一,如果前端是大促页面或秒杀入口,真实的用户点击行为本身就会有极端的瞬时并发,不加控制,下单请求会先把自己的下单服务打垄,根本轮不到网关限流出场。第二,主动限流能让商户把"该拒绝的请求"尽早挡在自己这一层,而不是等网关返回限流错误再处理——那时候用户已经感知到下单失败,体验已经受损。

实际做法上,我们倾向于在订单创建接口前面加一层基于令牌桶的节流闸,配合前端的提交按钮防抖、后端的排队队列,把真实的下单请求整形(traffic shaping)成相对平滑的曲线,再交给下游去调用支付网关的下单接口。另外提一句,如果调用频次短时间内远超历史基线,也容易触发网关侧的风控限额判定,这部分可以参考商户风控与限额冻结的说明。

持牌支付机构(在菲律宾对应 BSP 颁发的 OPS 或 EMI 牌照)通常会在接口文档里明确限流规则和异常交易判定逻辑,这也是合规审计的一部分——突然的调用暴增如果没有合理业务解释,风控系统本身就会介入复核。商户在设计并发方案时,最好把这类规则当成硬约束,而不是绕过的目标。

被限流之后怎么办:重试与指数退避的设计

即便做了前置节流,极端情况下调用仍然可能被网关判定为超限,返回 429 或者等价的限流错误码。这时候商户系统的重试逻辑设计就很关键——盲目地立刻重试,只会让本就紧张的调用配额进一步恶化,形成"越限流越重试、越重试越限流"的恶性循环。

比较成熟的做法是指数退避(exponential backoff)加随机抖动(jitter):每次重试的等待时间按指数增长,同时加入一个随机量,避免大量并发请求在同一时刻集中重试、再次形成洪峰。如果网关返回了 Retry-After 这类响应头,应该优先尊重这个值,而不是完全按自己的退避算法硬算。

async function callGatewayWithBackoff(orderPayload, maxRetries = 5) {
  let attempt = 0;
  while (attempt < maxRetries) {
    try {
      const res = await fetch('https://api.gateway.example/v1/orders', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          'Idempotency-Key': orderPayload.idempotencyKey,
        },
        body: JSON.stringify(orderPayload),
      });

      if (res.status === 429) {
        const retryAfter = res.headers.get('Retry-After');
        const baseDelay = retryAfter
          ? parseInt(retryAfter, 10) * 1000
          : Math.min(1000 * 2 ** attempt, 30000);
        const jitter = Math.random() * 300;
        await sleep(baseDelay + jitter);
        attempt += 1;
        continue;
      }

      if (!res.ok) {
        throw new Error(`gateway error: ${res.status}`);
      }

      return await res.json();
    } catch (err) {
      attempt += 1;
      if (attempt >= maxRetries) throw err;
      await sleep(Math.min(1000 * 2 ** attempt, 30000) + Math.random() * 300);
    }
  }
  throw new Error('max retries exceeded');
}

function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

这里有个容易被忽视的细节:重试次数不能无限加大,务必封顶,达到上限后要有明确的失败处理路径(比如进人工复核队列,或告知用户稍后重试),不能让请求无限期挂在后台。超时和重试的排查思路,也可以参考我们整理的常见错误码排查,里面列了几类容易和限流混淆的错误场景。

幂等性设计:防止重试带来的重复下单

重试逻辑一旦引入,就必然带来一个新问题:如果第一次请求实际已经被网关处理成功,只是响应因为网络原因没有回到商户系统,商户这边判断"超时"发起了重试,会不会造成重复扣款或重复下单?这正是幂等性设计要解决的问题。

做法上,商户系统生成订单时就应该带上一个唯一的幂等 key(通常用订单号或者订单号加业务维度拼出来的哈希值),把这个 key 放进请求头或请求体传给网关。网关侧如果识别到同一个幂等 key 的请求已经处理过,会直接返回第一次处理的结果,而不会重复创建一笔新订单。

{
  "merchant_order_no": "MO20261003883291",
  "idempotency_key": "order_MO20261003883291_v1",
  "channel": "gcash",
  "notify_url": "https://merchant.example.com/webhook/payment",
  "metadata": {
    "campaign": "1003-flash-sale",
    "retry_of": null
  }
}

几个实践上的注意点:幂等 key 的生成规则要在商户系统内部确保唯一且可复现,不能用随机数生成,否则重试时 key 变了就失去了幂等的意义;幂等 key 的有效期要和订单生命周期匹配;另外商户自己的订单表也要做唯一约束,双重兜底,即便网关那端出现极端情况下的幂等失效,商户系统内部也不会因为重复写入产生脏数据。

并发场景下的订单状态一致性

限流和重试解决的是"请求打不打得通"的问题,但高并发下还有一层更麻烦的问题:同一笔订单的状态,在并发场景下可能被多条链路同时修改。典型场景是支付结果通知(webhook)和用户主动查询订单状态这两条链路,在网络延迟不确定的情况下几乎没办法确定谁先谁后到达。如果订单状态更新逻辑没做好,就可能出现"支付成功的通知先到,查询接口返回的还是未支付"这种状态错乱,甚至被并发请求互相覆盖成错误的终态。

我们的处理原则是:订单状态机只能单向流转(比如待支付 → 已支付 → 已结算,不允许已支付被回退成待支付),状态更新操作要加数据库层的乐观锁或者基于版本号的条件更新,确保同一笔订单的并发写入不会互相覆盖;支付结果的最终判定,始终以网关的异步通知或主动查单接口为准,而不是以商户系统自己猜测的"应该成功了"为准。回调链路本身的验签和去重逻辑,也直接决定了并发场景下状态机踩不踩坑,这部分可以参考回调通知与对账闭环里关于重复通知处理的部分。

队列削峰:把瞬时洪峰削平再打给网关

前面提到的前置节流解决的是"控制调用频率",队列削峰解决的是"把不规则的洪峰变成规则的匀速流"。常见架构是在用户下单请求和实际调用支付网关之间,插入一层消息队列(常见选型是 Redis 的 List/Stream 或者独立的消息队列组件):用户提交下单请求后,先快速写入队列并给用户一个"已受理,处理中"的响应,再由后台 worker 按照网关允许的速率,匀速从队列里取出订单依次调用网关下单接口。

这样设计的好处是,前端瞬时并发再高,打到网关这一侧的调用速率始终被 worker 的消费速度控制住,不会出现"用户点击量等于网关调用量"的直接传导。代价是用户体感上会有短暂的排队等待,所以大促场景下前端的排队提示和进度反馈就变得很重要,这是产品体验层面需要配合的部分。

如果你还在对接阶段,想先验证这套削峰链路在限流边界条件下的表现,建议先在沙盒环境测试限流场景里把峰值并发、重试、幂等各个环节过一遍,再上生产环境,会比直接在真实大促上硬试错稳妥得多。

另外提一句,国内不少第三方支付中介并不持有 BSP 发放的 OPS/EMI 牌照,只是转接或代理资质,一旦交易量在大促期间异常放大,合规链路和风控响应能力的差距会比平时更明显地暴露出来。选网关这件事,建议和限流设计一起提前核实清楚。

常见问题

网关返回 429,是不是都代表我方调用太快?

不一定。429 也可能是网关整体容量紧张、特定通道临时限流,或者商户账户因历史交易被单独限额。遇到持续性 429,建议先联系网关侧核实原因,再决定是调整调用节奏还是申请提额。

幂等 key 应该设置多长的有效期?

一般建议覆盖订单的完整生命周期,外加一段缓冲时间,具体数值要结合业务的支付超时设置和网关侧的存储策略来定,不同网关的默认实现也不一样,接入前最好直接问清楚。

队列削峰会不会让用户觉得下单变慢了?

短时间的排队感是存在的,但只要前端给出清晰的处理中状态和等待提示,用户体验上通常可以接受,比"点击直接报错"要好得多。削峰的目标不是消除等待,而是把不可控的失败变成可控的延迟。

固定窗口限流的"临界突刺"问题,商户侧能规避吗?

商户侧没办法改网关的限流实现,但可以通过前置节流把调用曲线整形得更平滑,降低撞到窗口边界的概率,也可以在设计重试退避时特意避开紧贴窗口边界的时间段。

高并发下,重复支付通知要怎么处理才不会影响订单状态?

核心是给每条通知提取一个唯一标识(比如网关交易号),处理前先判断是否已处理过,处理过的直接返回确认、不再执行状态变更。这一步和幂等下单是同一个思路的延伸,只是用在通知消费侧。

要不要在商户自己的系统里也实现限流,而不是只依赖网关?

建议要。网关限流是最后一道防线,商户自己的前置限流和排队是第一道防线,两层叠加才能既护住自己的系统,又避免把压力全部传导给网关。

说到底,限流和并发处理不是一次性配置完就能一直躺平的事,随着业务量级变化,阈值、重试策略、队列容量都需要跟着调整。如果你在设计高并发下单链路上需要具体的方案讨论,欢迎联系 @LouisSMARTPAY 或邮件 [email protected],我们可以根据你的实际并发量级和通道组合给出更具体的建议。

相关推荐