拉卡拉开放平台

突然一批请求被拒，错误信息都指向频次过高——这就是遇到了限流。理解限流的逻辑，才能做出正确的应对。

限流通常按哪些维度

被限流时的表现

• 返回明确指向频次的提示；
• 失败集中在请求量上升之后；
• 降低频率后自动恢复。

第三点是判断限流最直接的证据：如果降频就好转，基本可以确定是限流。

立刻重试为什么更糟

被限流说明已经超过了承受能力，此时再补上一批重试，只会让压力进一步上升，恢复时间反而更长。

更合理的做法是：先停下来，等一段时间，再逐步恢复。

退避重试的基本思路

1. 第一次失败后等待一个较短时间；
2. 再次失败则把等待时间拉长；
3. 达到重试上限后停止并标记，转人工或延后处理。

这种逐步拉长间隔的方式，既给了系统恢复的时间，也避免了无意义的持续冲击。

从源头降低调用量

• 能用批量的一次性提交，减少请求次数；
• 能用通知的就不轮询，把主动查询改成事件驱动；
• 能缓存的结果就缓存，避免重复查询同样的内容。

这三条做到，多数情况下根本不会碰到限流。

限流与错误提示

被限流时通常会返回明确指向频次的提示，而不是笼统的失败。这一点很重要：它让调用方能区分「限流」与「业务失败」，从而采取完全不同的应对。

突发流量怎么平滑

很多限流不是因为总量大，而是因为流量过于集中：定时任务集中在整点触发，就会在那一分钟形成尖峰。

• 给定时任务加上随机的启动偏移，避免同时触发；
• 把大批量任务拆成小批，分散到不同时段；
• 在调用侧加一个速率控制，主动削平尖峰。

主动控制节奏，比被动等待限流恢复要可靠得多——后者意味着你已经影响了业务。

重试要有上限

退避重试必须设置次数上限，否则在持续限流的情况下，重试会变成一场永不停止的循环。

1. 设定最大重试次数；
2. 达到上限后标记失败并落库；
3. 由后续的补偿任务或人工介入处理。

第三步不能省略：被放弃的请求必须有地方接住，否则就变成了静默丢失。

调用侧的自我保护

与其依赖对方的限流，不如自己先控制住节奏。在调用侧加一个速率控制，可以按设定的速度匀速发出请求，而不是瞬间全部涌出。

• 削平尖峰，避免触发对方限流；
• 让请求分布更均匀，整体成功率更高；
• 出问题时也更容易控制影响范围。

这个做法的收益在流量大的时候尤其明显，而且实现起来并不复杂。

限流的本质是保护，而不是惩罚。理解这一点，就不会把被限流当成故障去抢修，而是会先降速、再观察、最后逐步恢复。

把限流当成一种反馈信号来读，而不是一个需要绕过的障碍，调用方与服务端的关系会从对抗变成协作。

说到底，限流的存在是为了让系统在压力下仍能给出可用的结果。顺着这个逻辑去设计调用方式，很多麻烦根本不会出现。