限流与计费的失败语义：一次请求怎样不被扣两次、也不把余额扣成负数
一句话回答
限流与计费系统的稳定性主要取决于是否为每次请求定义了唯一幂等键，以及准入、预扣、结算三段各自的失败结果；算法选择并不是决定因素。文中给出三段状态机的分工、常见失败路径的对照表、账本只追加与周期性对账的做法，以及多副本近似计数、批量落账带来透支等边界条件。
限流与计费系统出问题，多数不是限流算法选错，而是“一次请求”没有唯一身份、每条失败路径没有确定结果。稳定性的落点在于：同一请求重复到达时结果一致，任何异常路径都不会把余额扣成负数、也不会留下无法解释的挂账。下面是设计层面的说明，不涉及任何具体产品的实现细节；文中的阈值、窗口长度、结算延迟都需要按自身流量与成本模型确定，本文不提供实测数据。
先给“一次请求”一个幂等键#
幂等键是整条链路的主键，作用域应至少是“租户 + 计费单元”，只用全局自增 ID 无法防止客户端重试造成的重复扣费。常见做法是客户端首次请求时生成键并在重试中复用；客户端未提供时由服务端派生，但派生规则必须保证重试可复现，否则等于没有幂等。键的保留时长要覆盖客户端最大重试窗口与对账周期，具体取值待按实际情况核实后确定。
三段状态机：准入、预扣、结算#
- 准入判定：限流计数，追求低延迟，可以是近似值。它回答“这次要不要处理”，不负责记账。
- 预扣：在调用上游之前按预估用量占用额度，并且是持久化的约束——余额不足即拒绝，保证并发下不会集体越界。
- 结算：按实际用量把预扣转为实扣，或整笔释放。释放与“结算为 0”只能选一种语义，并在代码里固定下来，否则对账时会分不清是漏记还是零消耗。
失败路径要有对照表#
| 情形 | 限流计数 | 额度 | 账本 |
|---|---|---|---|
| 准入拒绝 | 按口径计入或不计入，需固定 | 不预扣 | 不记账 |
| 通过后上游超时 | 计入 | 释放，或按已发生的上游成本结算 | 记一条带错误码的流水 |
| 客户端同键重试 | 视为同一次 | 不重复预扣 | 不重复记账 |
| 结算请求丢失 | 不涉及 | 保持挂账 | 由对账超时释放或转人工 |
这张表的价值在于：任何一条路径都有唯一归属。表中“按口径计入或不计入”一项看似琐碎，但它是后续对账能否对齐的前提，必须在实现前定死。
账本只追加，差异要能分类#
推荐把流水做成只追加（append-only）记录，余额是聚合结果而非可随意覆写的字段；如果为了查询性能保留可变的余额字段，就需要双写并用对账校验两者是否一致。对账不能只输出一个差额总数，而应输出分类码：预扣超时未结算、结算金额大于预扣、同键重复写入、上游失败但已计费。分类之后，每一类才能对应到具体的修复动作。
示例：预扣与结算的调用骨架#
// 未执行的示例：仅示意调用顺序与幂等要求，不是可运行代码
reservation = reserve(tenant, idemKey, estimate) // 同 idemKey 必须返回同一笔预扣
if (reservation == null) return 402 // 额度不足
try {
resp = callUpstream(request)
settle(reservation, actualCost) // 按实际用量结算
} catch (e) {
release(reservation) // 全系统只允许这一种失败处理方式
throw e
}边界条件#
- 多副本下的限流计数天然是近似的，允许短暂超额，但超额必须有上限并触发告警。
- 把逐次落账改为批量聚合能减少写入，代价是窗口内出现透支；透支额度需要显式配置，不能靠默认值。
- 跨区域强一致账本成本较高，常见取舍是“单区域强一致账本 + 区域级配额”，具体收益与延迟影响待按实际部署核实。
- 本文没有引用外部资料，也没有运行任何代码；涉及具体数据库选型、QPS 阈值与结算延迟指标的部分，均待核实。
