批量 IP 查询 API:速率限制下的架构设计
批量 IP 查询 API 让你在一次请求中解析多个地址,而不是每个地址调用一次。围绕它的架构归结为三个约束:最大批量大小、你被允许消耗的请求额度,以及你在多大程度上避免重复提出同一个问题。本文以 ipto 的批量端点提供的具体数字为例,介绍一种实用的设计。
批量 IP 查询端点接受什么
ipto 的批量查询是一个 POST 请求,发送至 /v1/ip/bulk,请求体为 IP 字符串的 JSON 数组。每次请求最多接受 100 个地址,处理前会去除重复项,响应是以 IP 地址为键的对象,每个条目的结构与单次查询结果一致,包含国家、城市、ASN、组织,以及 is_vpn、is_tor、is_abuser、is_datacenter 和 bogon 字段。批量查询是付费套餐功能,适用于 Pro 和 Enterprise,而 Free 套餐涵盖每天 1,000 次的单次查询,无需注册。当前的请求格式请查阅 API 文档。
重要的计费细节是,批量查询按条目收费。一批 100 个地址对每日额度的消耗就是 100,与 100 次单独查询完全一样。因此批量处理并不会延长你的配额。它节省的是网络往返、连接建立和客户端编排,而在你丰富日志文件或客户列表时,这往往才是真正的瓶颈。
围绕额度设计管道
由于每个地址都会消耗额度,最便宜的请求就是你从未发出的那个。先从过滤开始。私有和保留地址永远不会有有意义的地理定位,你可以在本地丢弃它们,或在它们产生任何成本之前用 bogon IP 检查器对其分类。对剩余集合去重,因为生产日志主要由少数重复访客、爬虫和 NAT 网关构成。在批处理器前面放一个哈希集合,通常是你能做的回报最高的改动。
然后添加一个以地址为键的缓存,其存活时间(TTL)应与你关心的数据变化速度相匹配。国家和 ASN 的映射在很长一段时间内是稳定的,所以几天是合理的。信誉标记变化更快,因为 ipto 的威胁情报源每 6 小时刷新一次,IP 和 ASN 数据集每天刷新,所以把一个判定缓存超过几个小时只会增加陈旧度,而节省不了多少。如果可以,请为不同字段设置各自的 TTL,或者以较短的 TTL 缓存整个结果。
- 在本地过滤 bogon 地址和明显无效的输入。
- 在任务内部以及与缓存之间去重。
- 将剩余地址分块,每组最多 100 个。
- 以有界并发发送各个分块,而不是一次性全部发出。
- 将结果写入缓存和目标存储,以地址为键。
并发、退避与每日窗口
每日额度是一个固定窗口,因此需要设计防范的失败模式是任务进行到一半时额度耗尽。在开始之前估算成本:唯一的非 bogon 地址数量就是该任务将消耗的请求数。如果它超过今天的剩余额度,就把任务拆分到多个窗口,先处理最有价值的地址,或者仅对风险最高的地址回退到单次查询。持久化进度,这样重启的任务可以从最后一个完成的分块继续,而不是从头开始。
使用适度的并发。通常几个并行的分块就足够了,因为每个分块已经承载了 100 次查询,而无限制的扇出只会让故障更难排查。遇到瞬时错误或超出额度的响应时,使用带抖动的指数退避重试,并把额度耗尽视为停止并稍后恢复的信号,而不是在紧密循环中重试。让每次写入都具有幂等性,这样重试的分块就不会重复插入行。
在批量查询与单次查询之间选择
对于注册表单或结账等实时路径,每个事件使用一次单次查询。延迟低,缓存会吸收重复请求,而且你只为实际到达的地址消耗额度。批量查询适用于离线工作:回填数据表、为一天的日志评分或审计允许名单。如果你的目标是风险评分而不是原始数据丰富,欺诈评分检查器会将 IP、邮箱、电话和 User-Agent 信号合并为一个 0 到 100 的评分,可以取代多次单独调用。关于各服务商免费套餐限额的更详细比较,请参阅我们的免费套餐速率对比。
最后,记录你自己的用量。跟踪每个任务消耗的请求数、缓存命中率,以及因 bogon 或重复而被丢弃的地址占比。这三个数字能让你远早于额度告警就知道架构是否运转良好。
在编写大批量脚本之前,先手动试几个地址:ASN 查询会显示你在日志中不断看到的某个网段归哪个网络所有,这常常让你可以用一个决策处理整个网络,而不是成千上万次单独查询。