号码状态查询的批量任务：切成几片跑才够快
名单从十万条涨到三百万条之后，单实例的号码状态查询任务开始跑不完一夜。这篇按场景讲分片执行怎么落地：切片键怎么选才不歪、各片进度怎么合成一个数、某片卡住靠什么发现、片数加到多少就该停，以及加机器之前要先用吞吐算一遍出口配额。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
周三晚上十点，运营把一份三百万条的名单丢进系统后台，附了一句「这个月做全量清洗，明早八点前跑完」。值班同学翻出上一次的记录：十万条跑了一个半小时。照这个速度，三百万条要一天半，群里等着的那句话没法回。
量级一上来，单实例的任务就跑不动了。常见情形是代码没改、凭据没换，只是名单大了三十倍，原来够用的那一套就撑不住了。
先别急着加机器，把时间花在哪一段看清楚。一次调用大致三段：请求往返、重试与退避、结果落库。
量小的时候瓶颈在往返，因为一条条串着等；量上来之后常常变成落库——每查一条写一行，几十万行的写入把数据库的 IO 吃满，进度就卡在别人看不见的地方。还有一种情况是调度：同一个实例既取任务又写结果，两边互相等锁。
判断方法很土但有效：把三段耗时分别打点，先跑一万条看各占多少。占了大头的那一段，才是分片要解决的问题。落库占大头时，多开实例只能把压力成倍加在同一个库上，得先把写库改成按批提交。
最直觉的做法是按条数切：三百万条切十片，每片三十万，十个实例并行。动作是对的，切法常常是错的。
如果名单是按号码段排序导出的，顺着切出来的片子会严重不均——有的片全是连号，有的片号码散在几十个号段上，查询耗时可差两三倍。片子快慢不一，整体完成时间由最慢的那片决定，平均切等于没切。
两个更稳的切法：按名单行号取模，或者按号码的哈希值打散，目标是让每片的号码分布与号码段无关。
另一个方向是业务切：同一个客户名下的多个号码落在同一片里，方便一次汇总。两种切法会冲突，量级不大的场景按业务切，全量清洗按打散切，选一种写进任务配置，别让每个开发自己决定。
十个实例各报各的进度，业务方看到的必须是一个数。合成这个数有个小坑：不能按片数取平均，要按条数加权。
片大小一致时两者没区别；不一致时按片数平均会出现「走到九成就再也不动」的观感，因为剩下那一片恰好是慢片。合成方式很简单，已完成条数除以总条数，另外补两个数：已经跑了多久，按最近十分钟的完成速率还差多久。
第三个数是心跳。每片隔一段时间上报一次自己的进度和时刻，超过阈值没有上报就把这片标成可疑。有了心跳，「进度停住」才从看截图变成看数据——批量任务的进度与回执该怎么给讲的是提交那一刻该拿回哪些字段，这里讲的是跑起来之后怎么盯。
片卡住的常见原因有三类：落进一个持续超时的号段区间、实例被别的任务抢了资源、结果写入遇到锁。三类从外表看都是同一句话——进度不动。
处置顺序是先摘出来再重跑：把可疑的那片单独标记，其余片继续跑；等定位清楚，再决定是原实例重试还是重新分片。
重跑要防两件事。一是配额被重复消耗，前面几片已经花掉的调用不会因为重跑退回来，重跑就是新的量，所以片不能切得太细——细到一片只剩几百条，一次重跑的代价会把省下来的时间又花掉。二是重复入库，重跑的片用「批次号加号码」做去重键，让同一号码的旧结论被覆盖，而不是插成两行。
片数不是越多越好。所有实例共享同一份出口配额，片数加到超过配额允许的并发之后，等待只是从自己的队列挪到了限流那一侧，整体完成时间不会再降，反而多出一批超时与重试。
靠谱的做法是先测出当前配额下的稳定并发，再倒推片数：可用并发除以单片并发，得到的数才是有意义的片数上限。这一点在并发梯度怎么定里给过测法，把限流跑成常态讲的是同一件事——限流不是故障，是容量的一部分。
跨地域部署时，分片还要跟出口绑定：哪个出口连哪个资源池、配额怎么分，两地调用的出口与配额怎么划分里有取舍。
看三件事。切片键有没有与号码段解耦，每片的号码分布是不是均匀；进度是不是按条数加权合成，并且带心跳；片数是不是按可用并发倒推出来的，而不是拍一个「越细越快」。三条都成立，名单从十万涨到三百万时，你要改的只是任务配置里的一个数，而不是陪着跑一个通宵。
估算分片规模时还得先摘掉一类号码：由转售企业发售的号段、只用于设备联网的卡片、机主登记在境外运营商的号码，这几种在切片之前就该标出来，它们在任何一个分片里都拿不到结论，却会实打实占掉一份出口配额。
这类任务能拿到什么结论，由接口能力决定：直连移动、联通、电信三网，八种状态与携号转网识别是基础，鉴权走请求头携带 AppCode，按次计费、即买即用，字段含义与错误码口径以商品详情页文档为准，【号码状态查询批量接口】的控制台里能对着看调用量与配额。
文章评论
发表评论
请先注册/登录后评论