名单高峰期的号码状态查询：把限流跑成常态
大促前一天收到八十万条名单，要求次日早上跑完。这篇按场景讲清批量号码状态查询的取舍：先用吞吐反推并发、把限流当常态处理、以及为什么落库常常比调用更慢。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
大促前一天下午，运营把八十万条名单丢过来：明天早上八点前要跑完，空号全部剔掉。
第一次跑，跑到十几万条就停了。日志里全是限流响应，重试又把配额吃掉一半。第二次跑，加了并发，结果数据库写入成了瓶颈，队列越堆越长。
这个场景在名单量级的业务里几乎每年都会重演一次。它不难，但需要几个反直觉的判断。
取号、调用、落库是三种节奏。取号很快，调用被 QPS 卡着，落库如果逐条写库，可能比调用还慢。
三段分开跑、各自设并发度，比一个线程池包打天下稳得多。落库那段改成批量写入，往往比调并发带来的提升更明显——这也是很多人忽略的地方。
正确的顺序是先算再配：名单量除以可用时长，得到每分钟需要处理多少条，再结合单次调用耗时估算并发，最后和接口的 QPS 上限比一比。
算出来超过上限就分时段跑，别硬冲。被限流之后的重试开销，比错峰执行大得多。内部令牌桶速率设在上限的七八成，把余量留给补跑和临时排查。
把限流和失败分开处理，是这套系统能不能跑稳的分水岭。
限流走退避，失败区分可重试与不可重试。退避一定要带随机抖动，否则所有 worker 会在同一毫秒一起重试，制造一个新的尖峰，然后被再限流一次。退避起点也别定得太短，一两秒的间隔在几十个 worker 并发下几乎等于没有退避。处理顺序上，限流优先于失败重试：先把配额省下来给还没查过的号码，再回头补已经失败的那些。
重试次数和整体预算挂钩。超限的任务进死信队列，留给人工确认——让失败任务无限重试，名义上追求成功率，实际是在给一条坏数据付钱。
队列短暂积压很正常，持续增长才是问题。前者说明消费能力够用，只是赶上波峰；后者说明进来的比出去的多，这时候加并发往往解决不了，因为瓶颈可能在落库段，或者藏在某个慢查询里。
看曲线的斜率比看某次任务的总耗时有用得多。曲线平着走，就安心等它跑完；曲线抬头，先去看消费端的处理速度。
八十万条、一夜时间，这个约束下最该做的是排序而不是提速：先把最需要触达的那部分名单排在前面，让业务在早晨有可用结果，剩下的边跑边补。
具体做法是按业务优先级拆批次，高优先级批次给足并发，低优先级批次放到非高峰时段。需要先验证批量链路时，可以用【手机号在网状态 API】按次计费跑一批真实名单，用实测耗时来定并发参数，比套用别人博客里的数字靠谱。
任务跑完之后，值得花二十分钟看三件事：状态分布的占比是否和上次接近、失败任务的分类统计、以及实际调用量与预估的差距。这三项里任何一项异常，都说明名单质量或者调度参数需要调整。
名单里通常还混着几类查不到结论的号码——虚商号段、物联网卡、境外号码，落库时单独标记，别让它们污染状态分布。
文章评论
发表评论
请先注册/登录后评论