给云上接口加限流，先明确按什么计数

一个批量查询脚本持续调用接口，可能让其他用户的正常查询变慢。给部署在云上的应用增加限流时，除了设置请求数量，还需要明确计数对象和超限后的处理方式，才能让规则符合实际业务。

一、计数对象决定影响范围

限流可以按整个接口、租户或已认证用户分别计数。按IP地址区分调用方比较直观，但同一办公网络可能有多人共用出口，不能简单把一个IP当作一个用户。对于登录后的业务，应结合可信的身份信息设计规则，避免直接相信客户端随意填写的标识。

二、平均速率之外，还要考虑突发

用户打开页面时，可能同时触发多个查询。若只看一个时间窗口内的请求总量，窗口切换附近仍可能出现集中请求。选择固定窗口、滑动窗口或令牌桶等方案时，需要理解它们对突发流量的处理差异。阈值应结合接口成本和可承受容量验证，不能直接照搬其他系统的数值。

三、多个实例需要约定共同口径

应用扩展为多个实例后，如果每个实例都独立计数，整体允许的请求量可能随实例数量增加。需要先决定规则限制的是单个实例还是整个服务，再选择相应的计数方式。请求速率和同时执行的请求数也有区别：耗时较长的任务，即使调用频率不高，也可能持续占用资源。

四、让调用方知道怎样继续

超限时可以返回清楚的状态和提示。HTTP接口常用429表示请求过多，并可通过Retry-After说明建议等待时间。调用方应采用有间隔、有上限的重试策略，避免立即重复请求。交互查询与批处理任务，也可以根据业务优先级安排不同的额度。

上线前，用正常访问、短时突发和持续调用三类场景验证，检查受限范围与恢复行为。限流规则需要随着业务变化调整，并结合缓存、排队等方式共同管理负载。