大规模活跃号码筛选怎么规划：容量、批次、失败恢复与成本模型

大规模活跃号码筛选的容量，不是平台某一分钟跑得多快，而是整个系统在规定时限内能否稳定完成“准备—处理—验收—回连—异常复核”。如果下游每天只能验收两万行，上游即使一小时返回十万行，也只是把瓶颈推到Excel积压。

先定义四个容量变量

arrival_rate是每天进入的新号码；service_rate是完整验收后可用的号码；backlog是尚未完成的存量；freshness_window是结果仍能服务业务的时间。只有service_rate长期高于arrival_rate且能吸收峰值，系统才稳定。

把处理链画成容量表

为什么活动任务特别受时间约束

WhatsApp、Telegram、Zalo或Viber的活动结果都可能随时间变化。作业总耗时若接近freshness_window，第一批刚验收，最后一批的数据已不是同一观察窗口。规划时给每个cohort指定完成SLA和expiry。

用分片隔离容量风险

按平台、国家、来源和任务拆分不可变shard。高异常来源使用小片，稳定来源可适当放大。每片有输入数、hash、attempt、状态与负责人。失败只重跑片段，不重启整个百万号码作业。

设置恢复目标

成本按成功闭环计

单位成本分母不应是提交号码数，而是按时完成、可回连且符合用途的观察数。分子包括清洗、任务、存储、复核、重试、过期删除和事故处理。未知率或冲突率升高会让“每个可用观察成本”快速上升。

算一个容量情景

若每天到达8万唯一号码，完整service_rate为10万，理论余量仅2万。某天故障积压20万，即使恢复后到达量不变，也需10天消化。团队要么准备临时扩容与优先级，要么接受部分cohort过期并停止处理。

优先级不能只看客户价值

队列应综合业务截止、结果寿命、处理成本、用户影响和许可。已退出、用途结束或证据不足的记录在进入处理前剔除；高价值标签不能绕过许可，也不能让低风险服务客户永久饿死。

压测要包含故障

除峰值吞吐外，测试慢返回、缺列Excel、重复结果、网络中断、worker重启、映射冲突和数据库锁。观察是否产生重复写入、是否能从checkpoint恢复，以及积压是否在可接受时间清空。

容量看板的关键图

显示到达与服务率、队列年龄分布、最老shard、各阶段利用率、错误类别、重试预算、回连率及即将过期量。平均处理时间会掩盖长尾，应同时看P50、P95与超SLA数量。

什么时候应该停止扩容

当更多结果不改变业务决定、人工复核成为永久瓶颈，或结果在使用前已经过期，应缩小cohort和任务，而不是继续加机器。好的容量规划追求在有效期内完成必要观察，不追求处理尽可能多的号码。