「API 限流」标签下共 19 篇技术文章。按发布时间倒序排列，内容持续更新。
把同一 API Key 的限流计数留在本机、跨节点合并压到 100ms 一次批量对账，p99 从 1.6ms 降到 0.03ms，代价是千分之二左右的配额误差。GPU 拓扑感知调度的放置、切片、反碎片三件事，可以直接搬到 API 限…
限流可以近似、计费必须精确：用令牌桶加隔离舱做限流，用不可变事件加幂等键做计费，两边靠分钟级对账把数字对齐，并补齐限流器故障时的降级策略。
答案是：把约束尽可能前移。金额、配额、时间窗口写成不可混用的品牌类型，边界在构造器校验，请求状态迁移用枚举穷举，再配合原子扣减脚本与带唯一约束的幂等账本，让非法状态在写出来之前就被拒绝。
文章提出用策略外置把阈值写进版本库、先定计量口径再写计费实现、用不可变计费事件与三条对账线暴露差异，并把降级策略和演练制度化，让限流计费系统在人员变动后仍可交接、可定位、可追溯。
多租户 API 限流与计费的关键是分层限流、事件化计量、预扣幂等扣费与日终对账，再用故障降级和客户端退避保证配额不超卖、账本可重放、漂移可告警。
限流与计费必须一起设计：应把准入、计量、账本拆成三个只通过事件交互的正交行为，以追加写事件流为唯一事实来源，并用预扣—结算—释放与定时对账把误差收敛到可观测范围。
稳定 API 限流与计费必须共享同一套数据：先统一权重与用量事件口径，再用 Redis 令牌桶分级限流，并以预扣—结算—对账账本和依赖降级兜底，才能做到不超卖、不丢事件，又能用每日对账证明账目一致。
核心是三层限流加三阶段计费：边缘层用 Nginx 挡量，应用层用 Redis 令牌桶原子扣减并按接口成本差异化消耗，租户层管住日/月配额与并发；计费走预扣、结算、对账，靠唯一请求 ID 保证幂等不重不漏。
用令牌桶加 Redis Lua 实现原子限流来保护上游，用预扣—结算—对账三段式计费产出可核对的账本，两者以 request_id 串联但各自独立演进。
共 19 篇文章，第 2 / 3 页