资源站的带宽和数据库都不便宜，为防止被采集请求打爆，多数接口都设了访问频率上限。被限流不等于接口死亡，处理得当可以长期共存，处理不当则可能被封到彻底失联，所以每个站长都该认识限流这回事。
被限流的典型特征
最明确的信号是接口返回 429 状态码；另一种更隐蔽，表现为响应时间从几百毫秒涨到几秒，或间歇性返回空数据。区分限流和故障的方法很简单：降低请求频率后再试，恢复正常说明是限流，依旧异常才考虑接口本身出了问题。极端情况下对方会直接封禁，那属于采集接口安全防护讨论的范畴。
应对一：降频
在采集任务里控制单位时间的请求数，给请求之间加间隔，宁可拉长单次采集时间，也不要并发轰炸上游。苹果CMS后台的采集参数可以限制每次采集的数据量，把大批量任务拆成小批多次跑，压力自然摊开，接口的容忍度也会高很多。间隔设多少没有标准答案，可以从每个请求间隔一到两秒起步，观察一周的报错情况再微调；批量参数一次采几十条而不是几千条，任务拆得越碎，单次失败需要重跑的量也越小。
应对二：错峰
资源站的访问高峰通常在晚间，凌晨时段资源最充裕。把定时采集安排在低峰期执行，既不容易触发限流，采集速度也更快，具体计划任务的配置方法在苹果CMS定时采集教程里有完整步骤，照着做即可。凌晨一般指零点到七点这一段，资源站负载最低；如果源站在国外，还要考虑时差，对方的晚间高峰同样可能拖慢你的采集。
应对三：缓存与轮询
对接口的分类列表这类不常变化的数据做本地缓存，减少重复请求；同时在多个源之间轮询分摊请求量，单源压力随之下降。多采集源轮询策略给出了具体的轮询设计，长期运行的站点还可以上监控看板，观察各接口响应时间的变化趋势。分类列表这类数据一天更新不了几次，缓存设半天到一天都不为过，真正高频变化的只有影片数据，别把缓存时长一刀切。
把限流当作常态来管理
限流本身是资源站的正当自我保护，与其对抗不如适应：固定低频节奏采集、给每个常用源留出冗余、把响应时间纳入日常巡检。做到这三点，绝大多数限流都不会再演化成采集事故。