批量实名核验怎么并发？配额、限流与断点续跑的实操配置
批量身份核验三个高频问题:并发数=配额70-80%的分片结构、限流码识别+指数退避+降载恢复的处理三步、幂等键+状态机+结果分级三个必配机制。附批量核验Checklist。
批量核验（一次核验几百上千条身份信息）和单次核验的技术要求完全不同：单次核验拼的是"接得通"，批量核验拼的是"打得完"——在不触发限流、不重复计费、不错杀用户的前提下，把一个大批量安全跑完。
这篇回答批量场景最高频的三个问题：并发开多少合适、被限流了怎么办、怎么又快又不出错。
一、并发开多少：先问配额，再谈并发
最常见的错误是"服务器多少核就开多少并发"——批量核验的瓶颈从来不在你的机器，在服务商的并发配额。
正确的顺序：
第一步：确认配额。开通时或批量前，向服务商确认三件事：每秒/每分钟请求上限（QPS/RPM）、单日调用量上限、临时提额通道。以我们的平台为例，并发配额在开通时按业务场景约定，报名季、大促可提前申请临时提额——这个电话值得打，批量前 10 分钟的沟通省掉批量的全部事故。
第二步：并发数 = 配额的 70-80%。不把配额跑满是留出重试和查询的余量——重试流量也算在配额里，跑满 100% 的配额，第一次重试就是超限。
第三步：分片 + 间隔。单线程顺序跑几千条太慢，推荐"分片并发"结构：
import concurrent.futures, time
def run_batch(items, shard_size=50, shard_interval=1.0): """分片并发：片内并发，片间间隔""" results = [] for i in range(0, len(items), shard_size): shard = items[i:i+shard_size] with concurrent.futures.ThreadPoolExecutor(max_workers=10) as ex: futures = [ex.submit(call_verify, it) for it in shard] for f in concurrent.futures.as_completed(futures): results.append(f.result()) if i + shard_size < len(items): time.sleep(shard_interval) # 片间呼吸，避免压满配额 return results
片内 10 并发、每片 50 条、片间 1 秒——这个结构把"瞬时峰值"控制在配额内，总吞吐又是顺序执行的数十倍。
二、被限流了怎么办：识别、退避、恢复
触发限流的信号通常是特定错误码（限流码）或连续超时。处理三步：
1. 识别：把限流码（如 429 或服务商自定义的限流码）单独分类——它和"系统异常"不同，含义是"你太快了"，退避时长要按服务端的恢复节奏来。
2. 指数退避 + 熔断：收到限流码，当前分片暂停，等待时间指数增长（1s → 2s → 4s），并加随机抖动防止整批同时回来。连续多次限流触发熔断：整批暂停几分钟再恢复。
3. 降低并发续跑：熔断恢复后不要恢复原并发——降到原来的 50% 跑一段，稳定后再逐步升回去。限流是服务商在告诉你"当前速率超过我的承载"，收到信号还全速冲回去，第二轮限流只会更严。
千万不要做的事：遇到限流换 IP、多账号绕过——这不仅是违约，批量场景的多账号轮换会被判定为滥用，账号直接进风控名单。
三、又快又不错错：三个必配机制
1. 幂等键：批量里每条用业务单号派生幂等键，重试不会重复计费——这是并发的前提，没有它并发越高浪费越多。
2. 结果状态机：每条独立状态（pending/done/failed/timeout），单条失败不影响整批，跑完自动汇总哪些需要补跑——这套就是"断点续跑"的底座，细节见 CSDN 系列的《断点续跑的设计与实现》。
3. 结果分级处理：批量的"不一致"别自动判死——录入错误引导重填、真实不符才拒绝，两类失败分开处理。批量核验的价值不在跑完，在跑完之后那批"不一致"怎么处理。
四、一套批量核验 Checklist
□ 配额确认：QPS/日上限/提额通道，批量前打一次电话
□ 并发 = 配额 70-80%，分片并发 + 片间间隔 □ 限流码单独分类，指数退避 + 抖动 + 熔断 □ 熔断恢复后降载 50% 逐步升回 □ 幂等键全覆盖（业务单号派生） □ 断点续跑：明细状态落库，可 kill -9 恢复 □ 结果分级：录入错误重填 vs 真实不符拒绝，分开处理 □ 对账：批次结束核账单，争议单走申诉
相关资源
批量场景的具体配额因业务场景而异，开通时与商务确认，或通过试用申请后联调实测。