号码状态查询接进定时任务：补跑怎么编排
名单复核大多挂在定时任务上，一次要跑几十万条号码状态查询。任务中途失败、第二天重跑又重复提交，是常见情形。这篇讲调度侧的三件事：怎么分片、检查点记什么、补跑窗口开多大，顺带说清并发度为什么不是越大越好。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
接手一个名单复核任务的时候，最容易低估的不是接口，是调度。典型的排班是凌晨两点拉起一次，把当天到期的号码全查一遍，早上业务上班前结果必须落到库里。第一周跑得很顺，第二周某天没跑完，第三天手动重跑，额度当天被消耗掉一大截——排查才发现，问题不在接口，在这个任务既没有分片，也没有检查点。
号码数量在十万以内的时候，一把梭是最省事的写法：一个循环，从头查到尾，全部成功就算完成。这个方案在顺利的日子里看不出毛病，它对失败的容忍度是零。接口抖动、某条数据格式异常、进程被杀，任何一个都会让整批任务停在半路，而你不知道已经查到哪了。
分片不解决接口的稳定性，它解决的是失败之后怎么办。把当天的号码按区间或者按哈希切成若干份，每份独立跑、独立落库、独立记状态，一份失败不影响其它份。十万条切成二十份，每份五千条，单份耗时可控，重跑的代价也只有一份的量。
代价是编排多了一层。分片的边界要稳定，同一批号码今天切出来的份和明天要能对上，否则补跑时会漏或者重；份数要在任务配置里能改，别写死在代码里，名单量翻倍的时候第一个动的就是它。
检查点最容易记错的地方，是记成了「哪一批已经发出去」。请求发出去了不等于结果存下来了，中间隔着网络和写库两步，进程在这两步之间被杀，补跑时就会漏掉这一批。
正确的记法是记落库。每一份跑完，先把结果批量写进结果表，再更新这份分片的完成状态和完成时间，两个动作放在同一个事务里提交。下次拉起任务时先读状态表，只跑未完成或者完成时间过期的分片。
还有两个细节常被漏掉。一是分片状态要有「进行中」这个中间态，否则上一个进程还没死透，新的调度又把它拉起来，同一份跑两遍。二是分片的粒度要留出调整空间，名单量翻倍之后，原来的份数可能单份就要跑四十分钟，补跑窗口立刻不够用。
补跑不是失败了就一直重试，而是给一个时间窗：窗口内重试，窗口外顺延到下一个周期。窗口大小先看下游。早班要用结果，就必须在业务上班前跑完，凌晨到早上七点这段时间就是全部余量；如果下游是第二天中午才用，窗口可以放宽一整天。
窗口定完，再反推分片的耗时上限。二十份分片每份跑十分钟，一轮两小时能跑完，留四轮重试的余量就够；如果一份就要跑五十分钟，一轮接近一天，重试根本插不进去，那就得继续细分。
顺延也要有说法。顺延到下一个周期，意味着这批号码的结论日期会比正常晚一天，如果名单里有必须在今天完成触达的，就得单独挑出来走人工通道，而不是等第二天自动补。
调度侧看到任务慢，第一反应是把并发调高，这个动作经常帮倒忙。这类接口给的是按账号的 QPS 上限，并发超了换回来的是限流响应，重试又占掉同样的额度，实际吞吐反而下降。
更常见的瓶颈不在接口这一侧。查完要落库，写库跟不上，任务队列就会堆在内存里；如果结果表索引多、字段宽，批量写入的速度可能只有接口吞吐的三分之一。这时候加并发只会让内存压力更大。
合理的顺序是先看落库的批量大小，几百条一批改成一两千条一批，吞吐往往就能翻倍；批量调完再动并发，每次只加一档，观察任务的完整耗时和失败率，稳了再加下一档。
判断标准不复杂，看三件事。任务失败一次之后，补跑能不能在窗口内自动完成，不需要人工盯进度、手动重发；补跑重发的数量，能不能控制在总量的百分之十以内，超出说明分片粒度太粗；任务的完整耗时有明确上限，而不是跟着名单量线性涨到失控。
这三条都满足，调度这层基本可以不用管了。剩下的问题会回到业务侧——比如同一批号码被不同任务重复查到，重复提交的成因值得单独看一遍；分片跑完总有某一份一直失败，那就要按失败条目的处理逻辑排查，而不是无止境地重试。任务编排里的额度消耗最后会落到季度预算上，测算口径可以参考成本预算的算法。
范围上还有一类要提前标出来：号段由虚拟运营商放号、卡片是给设备联网用的物联网卡、号码登记在境外运营商名下，这三类在接口这一侧给不出结论。调度上应当单独归一个队列，别让它们混进失败重试里反复消耗额度。接口本身直连移动、联通、电信三网，返回八种状态，支持携号转网识别，鉴权走请求头携带 AppCode，按次计费、即买即用，字段含义以商品详情页文档为准：【手机号在网状态查询接口】。
文章评论
发表评论
请先注册/登录后评论