API宕机恢复后总限流与单用户限流场景下的请求优先级处理问题

首先可以通过官方给出的代理使用规则反推限流的基础定义：单用户限流的统计维度是用户身份（API密钥/账号ID），与请求IP无关，只要身份不同就算独立用户，单个身份每秒最多放行20次请求；全局总配额为每秒500次，所有用户的请求总和不能超过该阈值。

最终的有效响应数量完全取决于服务端的限流执行策略，主流实现分为三类： #

情况1：用户A为单个身份（无论使用多少代理） #

这是最符合常规「单用户」定义的场景，服务端先执行单用户维度限流，再执行全局限流：

• 单用户校验阶段：用户A的1000次请求都归属同一个身份，最多放行20次，剩余980次直接返回限流错误；用户B的20次请求刚好打满自身单用户配额，全部通过校验。
• 全局校验阶段：通过单用户校验的请求总共只有40次，远低于500的全局配额，全部放行。
• 最终结果：用户A每秒拿到20个有效响应，用户B每秒拿到20个有效响应。

情况2：用户A使用500个不同身份（对应官方提到的500个代理场景），服务端采用公平分配策略 #

大多数公开面向开发者的API会采用该策略，优先保障普通用户的合理请求：

• 单用户校验阶段：用户A的1000次请求拆分到500个独立身份，每个身份仅发送2次，全部低于20次的单用户上限，1000次请求全部通过校验；用户B的20次请求也通过单用户校验。
• 全局校验阶段：服务端优先为每个身份预留不超过单用户上限的配额，用户B的20次正常请求优先占用20个全局配额，剩余480个配额分配给用户A的请求。
• 最终结果：用户A每秒拿到480个有效响应，用户B每秒拿到20个有效响应。

情况3：用户A使用500个不同身份，服务端采用先来先服务策略 #

无优先级设计的极简服务会采用该策略：

• 单用户校验阶段和情况2一致，共有1020次请求进入全局校验环节。
• 全局校验阶段：按请求到达时间先后分配配额，直到500个配额耗尽。由于用户A的请求密度是B的50倍，大概率会占满全部全局配额，用户B的请求全部被拦截。
• 最终结果：用户A每秒拿到500个有效响应，用户B每秒拿到0个有效响应。

内容的提问来源于stack exchange，提问作者Gerrit