号码状态查询的耗时构成：平均两百毫秒为何跑一夜
号码状态查询单次平均两百毫秒，六十万条名单却跑了一整夜。这篇按场景拆开耗时的四段构成、长尾从哪里来、批大小与并发怎么配、超时重试为何放大等待，以及一个能交代的耗时目标怎么定。
🎁 免费试用手机号码状态查询 API
直连三网运营商 · 准确率 ≥99.9% · 支持携号转网识别 · 按次计费即买即用
运营递来一批六十万条的名单，要求第二天早上八点前跑完。上线前的容量评估里，团队按单次查询两百毫秒算过一笔账：开六十个并发，两个多小时就能收工。压测照着这个配置跑，前十分钟曲线很漂亮；半小时后队列开始往回涨，任务最后跑了一整夜。
账没算错，是口径选错了。两百毫秒是平均值，决定任务时长的是长尾那一小撮慢请求；长尾为什么会慢，得先把一次调用拆开看。
同一批号码的耗时分布并不集中在两百毫秒附近：一半请求在两百毫秒上下，另一小部分拖到一秒五以上。六十万条乘以两百毫秒，是三十三个小时的机器时间，摊到六十个并发上确实只要半个多小时；可只要有一成请求落进一秒五的那一档，多出来的等待就够把任务推到凌晨。
容量评估要用 P95 或 P99，不能用平均值。平均值会把长尾抹平，而排期是按最慢的那批定的；长尾还往往集中在同一类号码或同一个时间段上，只看总体分位数看不出这些团块。
把单次调用按时间轴切一刀，大致分成四段，各自的责任方不一样。
第一段是排队等待，发生在自己的进程里。worker 数量、队列深度、上游返回速度共同决定它有多长。这段最容易被忽略，监控上看不到「排队」这个指标，它藏在端到端耗时与接口耗时的差值里。
第二段是建立连接。短连接每次都要握手，几十毫秒的开销在几十万次调用上就是几个小时，连接池是这里最划算的改动。
第三段是上游处理，由服务方决定，按次计费的部分就在这里。自己能动的只有总量与错峰，调不了单次速度。
第四段是结果落库。单条写入与批量写入的差距常在两三倍以上，配合索引与事务的取舍，这一段完全可能超过前两段之和。
遇到任务跑不完，第一反应通常是「接口变慢了」。先别急着找服务方，把两张图对上：接口侧耗时直方图，和自己这侧的端到端耗时直方图。
接口侧分布稳定、端到端却有长尾，问题基本在自己这里——队列太长、落库打满、连接数不够，或者某个批次的号码恰好都落在一个热分片上。反过来，端到端长尾与接口长尾形状一致，才轮到去查上游波动、配额限流或者网络链路。
这两种情况的处置动作完全相反：前者加机器、拆批次、改写入方式；后者只能降并发、错峰，或者退避重试。判断错的直接后果是白加一批资源，长尾一点没少。
调优任务时，批大小和并发这两个参数一起往上加很常见，出问题之后却分不清是谁的锅。
合理的顺序是先固定并发，把批大小调到落库耗时不再明显下降为止；再按目标吞吐反推并发，并留出三成余量给补跑。批大小影响的是单次处理效率，并发影响的是同时有多少个请求在飞，两者作用在链路的不同位置，盯着同一组指标调，很容易互相掩盖。
判断有没有调过头，看四个数就够：P95 耗时、失败率、落库耗时、连接数。P95 与失败率同时上升，是并发过高的信号；落库耗时随批大小线性上升，说明批已经过大。
限流处理是这条曲线的另一面。被限流之后的重试会形成新的尖峰，这部分在名单高峰期的号码状态查询：把限流跑成常态里单独讲过，两篇对着看，判断会准一些。
超时时间设短，看起来能保护自己，实际会把长尾放大：请求超时返回了，上游那一次并没有被取消，照样占用配额；自己的任务记下失败，马上又发一次，于是同一条号码被处理两遍。调用量翻倍，慢请求也翻倍。
重试还有第二个问题。没有抖动的定时重试，会让所有 worker 在同一秒一起回头，制造一个规则的新尖峰，被限流之后再退避，循环就起来了。
约束写三条就够：超时时间按 P99 加余量定，不按平均定；重试次数与整体时间预算挂钩，超限进死信队列等人工处理；重试请求带上幂等标记，避免同一批号码在账单上出现两次。错误码怎么分类、哪些该重试哪些不该，可以参考空号检测接口常见问题：鉴权、并发与错误码里的处理次序。
目标不该是「尽量快」，而该是一句能写进需求的话：六十万条名单，四小时内跑完，失败率不超过千分之三，P95 不超过八百毫秒。
定这句话的顺序是反的——先定可用时长，再除出所需吞吐，最后看这个吞吐在 P95 口径下能不能达成。达成不了就在名单量、时长、准确度里让步：分批交付、错峰调度，非关键的那部分挪到第二天。
任务上线之后，按周看一次耗时分布就够了。分布形状比单点数字有价值：整体右移是上游变化，尾巴变厚多半是自己这侧的排队问题。
另外提一句覆盖边界：号码归属虚拟运营商号段、属于物联网卡，或者本身就是境外号码时，这类请求拿不到状态，统计耗时时应当单独归一类，别混进慢请求的分位数里，否则长尾会看起来比实际更糟。
想先把真实分布摸清楚，可以用【手机号在网状态 API】按次计费起步：直连三网，支持携号转网识别，鉴权走请求头携带 AppCode。先跑两周，把接口侧耗时和自己的端到端耗时对上，再定并发与批大小，比照着平均值拍板靠谱得多。
文章评论
发表评论
请先注册/登录后评论