1. 为什么要在自己的项目里养一份 IP 地理数据做数据录入软件这行久了会发现一个规律真正让人头疼的从来不是“录入”这个动作本身而是“录进来的数据准不准、用不用得上”。我这个项目的起点很朴素——标题里那套 IP 地理数据市面上有现成的接口也有现成的库但每次要接进自己的系统就得重新做一遍清洗、校验、落库、建索引做完还得担心数据过期。于是我把这套动作固化成一个小工具把 IP 地理数据批量录入本地库再用这份数据去保护站点、去自定义站点。它解决的是“IP 归属地数据从哪来、怎么存、怎么查得快、怎么用得稳”这一整条链路的问题。适合谁看如果你在做后台管理系统、内容站、电商站、API 网关或者你手里有一批访问日志需要做地域维度分析这套东西基本可以直接抄。前端同学可以只看第 5 章运维同学重点看第 3、4 章做数据管道的同学从头看。我不会假设你有很强的网络底层知识但我会假设你写过 SQL、跑过 Python 脚本知道 IP 地址长什么样。1.1 一个真实的需求场景站点被刷量之后的补救某公司的内容站有段时间被批量请求打得很惨日志里同一批 IP 段几分钟内换着路径扫注册接口被灌了几千条垃圾数据。最初的反应是加验证码结果正常用户的转化率掉了三成后来加频率限制又被分布式的请求绕过去了。真正让局面缓下来的一步是把访问日志里的 IP 拿出来做地域和网段维度的聚合——发现有相当比例的请求集中在少数几个数据中心网段归属地显示的城市跟站点实际用户分布完全对不上。按这个特征做了一层过滤垃圾请求的量级立刻降下来而正常用户几乎没有感知。这件事给我的启发是IP 地理数据不是拿来“展示”的是拿来“做判断”的。展示只是最表层的一步比如页脚显示“来自某地”。真正有价值的是把它变成一条条可以执行的规则这个网段属于机房还是家庭宽带这个地区的访问频次是否异常这个用户所在时区该给他看哪个版本的时间戳这些判断的前提都是你手里有一份结构规整、可以随手查询的 IP 地理库。而这份库从哪来这就是录入软件要干的事。它不是一个炫技的项目本质是一条数据流水线拉取、清洗、校验、入库、建索引、切换版本。听起来枯燥但每一步都有坑坑的位置还特别固定。1.2 整体架构录入软件在链路中的位置我把整个系统拆成四层从下往上说。数据源层负责提供原始 IP 地理数据常见形态有三种按网段切分的 CSV、二进制格式的库文件、以及按单个 IP 查询的在线接口。三者的精度、更新频率、体积差别很大后面 1.3 会细说。录入层就是我说的这个数据录入软件它做五件事格式识别、字段映射、合法性校验、去重合并、分批落库。这一层是整条链路里最容易被低估的部分因为脏数据几乎必然存在——国家名写成两种语言、城市名带不可见字符、网段起止写反、IPv6 混进 IPv4 表里。不在这里拦住后面查询层就得天天背锅。存储层是自建的数据库我选了“整数区间 二分查找”的模型理由在 2.1 展开。这个模型的好处是查询极快、改造灵活坏处是需要自己维护索引和版本。应用层分两条支线一条通往“保护站点”也就是风控规则引擎另一条通往“自定义站点”也就是多语言、多币种、时区、内容差异化。两条支线共用同一个查询接口但缓存策略完全不同——风控要的是实时和准确个性化要的是低延迟和高命中。四层之间我用一个约定隔开录入层只负责把数据变干净不做任何业务判断应用层只消费查询接口不直接碰库。这个约定听起来像教条但它救过我一次——某次数据源格式大改我只改了录入层的字段映射应用层一行代码没动就平滑过渡了。反过来如果业务逻辑里到处散落着“读 CSV 第 7 列”那次改版至少要拖两周。1.3 在线接口与离线库的取舍我为什么两个都要这是被问得最多的一个问题既然有在线接口为什么还要费劲自己建库先看在线接口。它的优势很明确单次查询就能拿到结构化结果字段通常比较全包含国家、省州、城市、经纬度、时区、运营商、是否是数据中心网段等维护成本几乎为零不用操心数据更新。缺点同样突出有网络依赖、有配额限制、有延迟成本。站点每天的访问量到十万级的时候如果每个请求都同步调一次外部接口页面首字节时间会被硬生生拉长几十毫秒接口一抖动整个站点跟着抖。这还没算上配额——批量回补历史日志的时候几十万条 IP 一次跑完很容易把当天额度打空。离线库反过来查询是本地内存操作微秒级没有配额概念想查多少查多少数据落在自己手里隐私上更可控。代价是要自己维护更新而且原始数据的精度和字段完整度通常不如商业接口。所以我的做法是分层使用主链路每个请求都要判定的场景走离线库保证延迟可控旁路离线分析、日志回补、疑难 IP 复核走在线接口拿更细的字段做补充。两边通过一个统一的查询函数封装起来业务侧只看到lookup(ip)不关心底层走的是哪条路。这个设计还有一个隐性好处在线接口返回的结果可以做抽样比对用来监控离线库的准确率。我设了一个每天 200 条的抽样比对任务偏差率超过阈值就告警——这个机制后来帮我发现过一次数据源更新滞后的问题。有一点要提醒不要把在线接口当成“绝对正确”的参照物。地理定位本质上是概率推断同一个人用手机在两地之间通勤上午查是一个城市下午查是另一个城市这不是谁的错。做规则的时候一定要给“不确定”留出位置具体在 4.3 讲。2. 数据录入软件的设计与字段规范2.1 表结构怎么定把 IP 段存成整数区间先说结论不要用字符串存 IP也不要用字符串比较做范围查询。IPv4 地址本质是一个 32 位无符号整数192.168.1.1转成整数就是3232235777。把网段存成(start_int, end_int)这样的闭区间查询就退化成一次“给定数字找包含它的区间”的问题用二分查找在有序数组上做复杂度 O(log n)。字符串方案的问题在于9.1.1.1 10.1.1.1是成立的按字典序但数值上 9 开头的地址小于 10 开头的地址排序全乱范围查询直接失效。表结构我用了两张表一张存区间一张存地理实体靠 ID 关联CREATE TABLE geo_entity ( geo_id INTEGER PRIMARY KEY, country_code CHAR(2) NOT NULL, country_name VARCHAR(64), region_name VARCHAR(128), city_name VARCHAR(128), timezone VARCHAR(64), latitude REAL, longitude REAL, is_datacenter SMALLINT DEFAULT 0 ); CREATE TABLE ip_range_v4 ( start_int INTEGER NOT NULL, end_int INTEGER NOT NULL, geo_id INTEGER NOT NULL, confidence SMALLINT DEFAULT 0, version INTEGER NOT NULL ); CREATE INDEX idx_range_v4 ON ip_range_v4(version, start_int, end_int);为什么拆两张表因为地理实体的重复度极高——同一个城市可能对应几千个网段如果每行都存一遍城市名和时区表体积会膨胀好几倍更新一个城市名还得扫全表。拆开之后区间表只存三个整数紧凑得很。实测下来200 万条区间记录在 SQLite 里占的空间大约 90MB拆表之前是 340MB差了将近四倍。confidence字段是给自己留的后路。不同数据源对“这个网段定位到城市”的置信度不一样我统一映射成 0-100 的分数国家级别 30省州级别 60城市级别 85有运营商或建筑级信息的 95。风控规则里会用到这个分数——低置信度的记录只用来做粗筛不参与封禁类决策。version是版本号配合 3.3 的滚动切换。这一列看着多余实际上是整个录入软件能“不停服更新”的关键。IPv6 单独建表结构一样但用 TEXT 存 128 位地址的前缀。这块数据量小得多我暂时没做深度优化够用就行。2.2 数据源清洗把五花八门的格式拉齐原始数据到手的第一个小时基本都在跟格式搏斗。我踩过的典型情况整理成一张表方便你对照现象典型表现处理方式网段起止写反start end交换两值并记一条告警日志网段重叠两条记录区间有交集保留 confidence 高的另一条裁剪CIDR 混入区间表出现1.2.3.0/24解析成起止整数再入表城市名带不可见字符尾部有\u200b或多余空格统一 strip 正则过滤控制字符国家名中英混杂同一国家两种写法建映射字典落到 ISO 两位码时区写成偏移量08:00转成 IANA 时区名如Asia/ShanghaiIPv6 混进 v4 表点分十进制解析报错按冒号数量分流到不同解析分支空值与占位符-、N/A、null统一转 NULL不参与城市级判定这张表里最坑的是“网段重叠”。理论上 IP 段不应该重叠现实中不同批次的数据合并时经常出现因为数据源更新时旧段没删干净。如果不处理二分查找会命中哪个区间完全看运气同一个 IP 两次查询结果不一样排查起来能让人怀疑人生。我的处理是入表前做一次全局排序 扫描合并遇到重叠就按置信度取舍同时把冲突记录写进一张conflict_log表方便回溯是哪一批数据引入的。另一个容易被忽略的是编码问题。某些数据源的城市名用本地语言写文件头却声明 UTF-8读进来是一堆问号。我的做法是读取时先按字节嗅探UTF-8 失败就退到 GBK 尝试两个都失败就整行跳过并计数。跳过率超过 0.5% 就停止导入——这通常意味着文件整体不是你以为的那个格式硬着头皮录进去只会污染库。提示清洗阶段一定要保留“原始行号”。出了问题时你能靠行号快速定位到源文件的哪一行比只知道“有 3 条数据异常”有用得多。2.3 录入流程分批、事务、断点续跑录入这件事小数据量怎么都好说上了百万行就必须考虑三件事内存、事务、中断。内存不要一次性把整个文件读进列表再处理。我一开始就是这么干的40 万行的 CSV 读进内存后Python 进程占了 1.2GB机器直接开始换页。改成流式迭代后峰值内存压到 200MB 以内。具体做法是生成器逐行 yield每攒够一批就落库并清空缓冲。事务每行一个事务是最慢的做法磁盘 fsync 次数太多。我按批提交一批 5000 行。这个数字不是拍脑袋来的——我试过 500、1000、5000、20000 四档在本地 SSD 上录入 40 万行的耗时分别是 62s、38s、21s、23s。5000 行是拐点再往上收益递减而单次事务失败要回滚的数据量却变大得不偿失。断点续跑录入过程中机器重启、脚本被杀、数据库连接超时都是常事。我加了一个import_progress表记录“哪个文件、处理到第几行、本批次是否已提交”。重跑时从断点继续不会重复插入。这里有个细节进度记录必须在事务提交之后写顺序反了会出现“进度记了但数据没进去”的空洞比重复插入更难查。整个流水线的伪代码大概长这样def import_file(path, batch_size5000): buf [] for lineno, row in enumerate(stream_rows(path), start1): rec normalize(row, lineno) # 清洗 校验 if rec is None: skipped 1 continue buf.append(rec) if len(buf) batch_size: commit_batch(buf) # 单事务写入 save_progress(path, lineno) # 事务提交后再记进度 buf.clear() if buf: commit_batch(buf) save_progress(path, lineno)commit_batch里我用的是executemany而不是拼 SQL 字符串除了防注入还有个现实原因拼出来的超长 SQL 在某些驱动上会撞到语句长度上限报错信息还特别模糊。3. 核心实现录入与查询的代码骨架3.1 批量录入脚本5000 行一批的理由接着上面的批次大小说。除了耗时还有一个因素决定批次大小锁的粒度。如果录入和查询共用同一个数据库一批写入时间太长会阻塞查询。5000 行在 SQLite 上的写入耗时大概 0.25 秒这个量级的锁等待对线上查询基本无感换成 20000 行一批单次写入 0.9 秒查询侧就会出现明显的毛刺。SQLite 我还调了几个参数效果比想象中大PRAGMA journal_mode WAL; -- 读写不互斥 PRAGMA synchronous NORMAL; -- 牺牲极端断电安全换速度 PRAGMA cache_size -64000; -- 64MB 页缓存 PRAGMA temp_store MEMORY; -- 临时表放内存journal_modeWAL是最关键的一条它让读操作不被写操作阻塞。改之前录入期间查询延迟能飙到 800ms改之后基本维持在 20ms 以内。synchronousNORMAL意味着极端断电情况下可能丢最后一个事务对 IP 地理数据这种可以重跑的场景完全可以接受——但如果是订单类数据请老老实实保持 FULL。如果你用的是 PostgreSQL思路类似但手段不同COPY命令比INSERT快一个数量级40 万行用COPY FROM STDIN大概 6 秒索引建议先删后建录完再CREATE INDEX比边插边维护索引快两三倍。这个技巧在大批量回补历史数据时特别好用。3.2 查询层二分查找与缓存查询的核心是“给定 IP 整数找出包含它的区间”。数据按start_int升序排列后用二分找到最后一个start_int ip的位置再检查该位置的end_int ip即可。import bisect class RangeIndex: def __init__(self, rows): rows.sort(keylambda r: r[0]) self.starts [r[0] for r in rows] self.ends [r[1] for r in rows] self.geo [r[2] for r in rows] self.conf [r[3] for r in rows] def lookup(self, ip_int): i bisect.bisect_right(self.starts, ip_int) - 1 if i 0 and self.ends[i] ip_int: return self.geo[i], self.conf[i] return None, 0把starts、ends、geo拆成三个平行数组列式存储比存对象列表快很多。原因是 Python 对象有额外开销遍历时缓存不友好。我实测过100 万条记录对象列表每次查询约 8 微秒平行数组约 1.6 微秒差了五倍。内存占用差距更大——对象列表 300MB 以上三个整数数组用array模块存是 12MB 左右。缓存分两层。第一层是进程内 LRU缓存最近查询的 10 万个 IP命中率在真实流量下大概 60%-75%。第二层是 IP 段聚合把 IP 的前 24 位IPv4 的 /24 网段作为缓存 key而不是完整 IP。这个改动把缓存命中率从 70% 提到了 92%因为同一网段的用户大概率落在同一个地理区域。代价是精度损失——一个 /24 里的 256 个地址被当成同一个位置实际误差最多到区县级用于个性化完全够用用于风控则需要谨慎4.3 会讲怎么处理。缓存还有一个坑不要缓存“查不到”的结果。未收录的 IP 查出来是 None如果这个 None 进了缓存等数据更新后依然返回 None看起来像数据没生效。我的做法是未命中结果只缓存 5 分钟命中结果缓存 1 小时。3.3 增量更新与版本切换不锁表IP 地理数据每月都在变更新必须有但不能停服。我用的是“影子表 版本号”方案。新建一张ip_range_v4_new把新数据全部录进去建好索引。校验通过行数、覆盖率、抽查比对都过之后在一个事务里做三件事更新一个配置表里的active_version把旧版本标记为待清理提交。查询层每次查询时读取active_version这个值缓存在内存里5 秒刷新一次带上版本号去查。这个方案的妙处在于没有任何锁表操作旧数据在新版本生效的那一刻起才不可见之前的所有查询都正常返回。清理旧版本可以延迟到低峰期做甚至保留两个版本以支持快速回滚。BEGIN; UPDATE config SET value 202406 WHERE key active_version; COMMIT; -- 低峰期执行 DELETE FROM ip_range_v4 WHERE version 202405;要注意的是active_version的读取频率。如果每个请求都去查一次配置表数据库压力不小。我把它放在进程内存里5 秒同步一次切换的延迟就是 5 秒。对 IP 地理数据这种更新频率来说5 秒的生效延迟完全无所谓。还有一个细节新版本上线前必须做覆盖率对比。我用同一批 1 万个抽样 IP分别用新旧版本查询统计“结果一致率”和“从有结果变成无结果”的比例。后者如果超过 1%说明新数据源有问题宁可不上也不要上。这个检查帮我拦住过一次数据源裁剪失误——新版本漏了整整一个大洲的网段。4. 用地理位置数据保护站点把风险挡在业务之前4.1 分层风控先把流量的“来路”分级“保护站点”这个说法容易被理解成上一套防火墙其实不是。IP 地理数据在防护里的作用是给每个请求补充一个“来路画像”让后续规则有依据。我的分级是这样的等级判定依据处理策略L0 可信家庭宽带网段 高置信度城市 历史行为正常全量放行不做额外校验L1 正常普通网段置信度中等正常处理只记录L2 存疑数据中心网段或归属地与声明地区严重不符加轻量校验如限频、要求完成一次交互L3 高危数据中心网段 高频 短时间多账号行为拦截或转人工审核这里要强调等级不是判决是优先级。L3 不等于“一定是坏人”只是“值得多看一眼”。把 L3 直接等同于封禁是误杀的主要来源具体见 4.3。分级依据里“数据中心网段”这个字段特别有用。它来自数据源的标注标识某个网段属于云服务商或机房而非住宅宽带。正常用户的家庭网络几乎不会落在这类网段里而批量请求工具往往跑在云主机上。这个特征单独用误判率不低有些企业办公网也走机房出口但叠加上频次和行为特征之后判别力就很强了。4.2 规则落地的三种形态边缘、应用、异步同一个判断放在不同的位置执行效果差别很大。边缘层反向代理或 CDN 边缘适合做粗粒度的拦截整段网段拒绝、按国家或地区做访问范围控制、简单的频率阈值。优势是请求根本进不到应用服务器成本最低劣势是规则变更需要重载配置而且边缘能拿到的上下文有限。Nginx 的geo模块可以加载网段列表做映射配置大概是这样geo $risk_level { default 1; include /etc/nginx/geo/datacenter_ranges.txt; # 值映射到 3 10.0.0.0/8 0; # 内网段直接放行 } map $risk_level $limit_key { 3 $binary_remote_addr; default ; } limit_req_zone $limit_key zonerisky:10m rate5r/s;limit_req_zone的 key 为空时不生效这个技巧让我只对高风险等级做限流正常流量完全不受影响。这种“按条件启用限流”的写法在文档里不显眼但实战中极其有用。应用层适合做带业务上下文的判断登录接口按地区做二次验证、注册接口限制同一网段的账号创建速率、支付接口校验账单地区与访问地区的一致性。应用层能拿到用户 ID、设备指纹、历史行为判断更准代价是消耗服务器资源。异步层适合做回溯分析把请求日志带上地理字段落盘离线跑聚合任务发现异常模式后再反哺前两层。异步层不影响实时性能是最安全的试验田。我的很多规则都是先在异步层跑一周看误报率确认没问题再往边缘层搬。三层之间要有清晰的职责边界否则会出现“同一个 IP 在边缘被拦、在应用层被放行”的混乱。我的约定是边缘层只做“明显不该来”的拦截应用层做“可能需要确认”的校验异步层只观察不干预。4.3 误杀控制白名单、灰度与申诉通道这一段是整章最重要的因为防护系统最大的风险不是漏放是误杀。第一不确定就降级。查询返回的confidence低于 60 时不要用它做拦截决策最多用来调整限频阈值。数据库里查不到的 IP一律按 L1 处理不因为“未知”就判为高危。未知 IP 的量在真实流量里通常占 3%-8%全部按高危处理误杀率会高得离谱。第二白名单要分层。我设了三层全局白名单内部服务、合作方固定出口、业务白名单某个业务线自己的合作渠道、临时白名单运营手工加的带过期时间。第三层最容易被滥用所以强制要求填过期时间最长 7 天过期自动失效。第三灰度放量。任何新规则上线先只对 5% 的流量生效观察 24 小时。观察指标不是“拦截了多少”而是“误杀申诉量”和“正常业务指标有没有波动”。这两个指标里后者更重要——很多误杀用户根本不会申诉直接走了。第四给不确定的流量一个出口。对 L2 存疑流量我不用直接拦截而是要求完成一次轻量交互比如页面停留超过 2 秒、完成一个简单的滑块。这类交互对真人几乎无感对批量脚本是硬门槛。注意任何基于地理位置数据的拦截规则都必须能解释“为什么拦”。我在规则配置里强制要求填reason字段出问题时能一眼看出是哪条规则命中。没有 reason 的规则不允许上线这条规矩救过我好几次。4.4 一套可以直接抄的判定流程把上面的东西串起来单个请求的判定大概是这样走的def assess(ip, ua, path, recent): geo, conf index.lookup(ip_to_int(ip)) if geo is None: return L1, geo_miss if ip in global_whitelist: return L0, whitelist if geo.is_datacenter and conf 85: if recent.hits_1min 30 and recent.distinct_paths 10: return L3, dc_scan return L2, dc_low_conf if path.startswith(/api/) and conf 60: return L2, low_conf_api return L1, default这段代码没什么花哨的地方但每条分支背后都对应一次线上事故的教训。distinct_paths这个条件就是后来加的——只看请求数会把正常的高频轮询接口误判加上“路径分散度”才准确。5. 用地理位置数据自定义站点体验层面的收益5.1 语言、货币、时区三件套“自定义站点”听着像是要做一套复杂的推荐系统其实收益最大的三件事特别朴素语言、货币、时区。语言按 IP 归属地给一个默认语言但一定要允许用户手动切换并且切换后记住选择。用户的手动选择优先级永远高于 IP 推断。我见过太多站点犯这个错用户切到英文刷新页面又变回中文只因为 IP 在国内。这个体验损伤比不自动切换还严重。货币电商站按地区展示默认货币价格换算要小心。不要用实时汇率直接乘把换算后的价格缓存一段时间我用 15 分钟否则同一件商品两次刷新价格不一样用户会觉得你不靠谱。另外某些地区的价格敏感度差异很大直接按汇率换算常常不合适这块需要业务侧自己定技术侧只提供“地区”这个输入。时区这个最容易做收益也最直接。订单时间、活动开始时间、日志时间戳全部按用户所在时区渲染。实现上不需要 IP 数据也能做——浏览器能拿到时区——但当用户还没执行 JS 时比如邮件、服务端渲染的首屏IP 数据就是唯一的来源。所以我的做法是服务端用 IP 推断给初始值客户端 JS 拿到真实时区后覆盖并上报。两者不一致时以客户端为准同时记一条日志用于监控 IP 库的准确率。这三件事的投入产出比极高加起来不到一天工作量用户感知却很明显。相比之下花两周做的“个性化推荐”在流量不大的站点上往往看不到效果。5.2 缓存与 Vary 头最容易翻车的地方按 IP 判断地区来做内容差异化最容易踩的坑是缓存串味。假设你的页面按地区展示不同的推荐内容CDN 把第一个访问者的页面缓存下来后面所有人都看到同一个版本。这在测试环境完全发现不了上线后就是一场灾难。解决思路有两条。第一条是把地区编码进缓存 keyCDN 层面按国家或地区分缓存例如/page?regioncn。这条路的优点是简单直接缺点是缓存命中率下降——分成 20 个地区就是 20 份缓存每份都要单独回源。我的做法是只对国家维度分缓存通常不超过 10 个有效国家更细的城市级差异化放到客户端做。第二条是用 Vary 头。如果你按Accept-Language做内容协商必须加上Vary: Accept-Language否则缓存会把中文页面返回给英文用户。但要注意Vary加得越多缓存命中率越低因为每个维度组合都是独立的缓存条目。Vary: Accept-Language, Accept-Encoding Cache-Control: public, max-age300, s-maxage600第二条路看起来更“标准”但实测下来我倾向于第一条——显式编码在 URL 里排查问题的时候一眼就能看出这个缓存属于哪个地区比翻 Vary 头快得多。还有一个细节不要在服务端根据 IP 做重定向来切换语言。比如检测到日本 IP 就 302 到/ja/。这个方案对搜索引擎极不友好爬虫的 IP 可能在任何地方抓到的内容和用户看到的对不上。正确做法是在同一 URL 下返回不同语言的内容用hreflang标注或者在客户端做切换。5.3 内容差异化与 A/B 的边界再往上一层就是内容差异化不同地区展示不同的活动、不同的商品排序、不同的推荐位。这块我的建议是先用数据说话再动手做。拿历史访问日志跑一遍地理维度的聚合看不同地区的用户行为到底差多少。我做过一次分析发现两个地区的用户点击分布相似度高达 90%那这种情况下做地区差异化纯属浪费人力。反过来另一个案例里某两个地区的支付方式偏好差异巨大那这个差异化就非常值得做。A/B 实验和地理定位结合的时候有个陷阱分流必须按用户 ID 哈希不能按 IP。按 IP 分流会导致同一个用户换个网络就看到另一个版本实验数据全废。IP 数据在这里的正确用法是“作为分层维度”——比如你想知道新方案在某个地区效果如何就在实验分析时按地区切分数据而不是按地区分配实验组。另外一个必须说的边界差异化不等于歧视。同一个服务不同地区的用户应该享受到同等的核心功能差异化的只能是表现形式语言、货币、内容排序和运营策略。这条线要划清楚否则技术上的“优化”很容易变成业务上的问题。6. 常见问题与排查技巧实录6.1 定位不准的六种典型表现“这个 IP 查出来的位置不对”——这是我收到最多的反馈。实际情况千差万别我整理成一张速查表现象根因处置方式城市对了区县错了数据源本身只到城市级降低该字段置信度不用于精细判定移动网络定位漂移运营商出口节点与用户实际位置不同移动网段只信到省州级企业专线定位到总部出口 IP 属于总部机房结合 ASN 字段判断企业网段放宽同一 IP 结果前后不一缓存穿透或版本切换中检查 active_version 同步间隔新分配 IP 查不到数据源更新滞后未命中走在线接口兜底IPv6 全部命中不到表没建或前缀长度不匹配单独校验 IPv6 分支这里面最值得展开的是移动网络定位漂移。移动用户的 IP 常常是运营商核心网出口一个出口后面挂着几十万用户地理位置可能对应到省会城市而不是用户所在的三线城市。如果你的业务需要城市级精度比如本地生活服务必须接受“移动网络只能给到省级”这个现实用其他信号GPS、用户填写地址来补充。硬要拿 IP 做城市级判定错误率会让你怀疑数据质量。企业专线的情况类似。某公司的出口 IP 注册在总部所在地但员工可能分布在十几个城市。这类网段的地理字段对“人在哪”判断力很弱但对“这人属于哪个组织”判断力很强——如果能拿到 ASN自治系统号或组织名称字段用组织维度做判断会准得多。6.2 性能与内存几条实测数据性能这块我做过一轮压测数据放在这里供参考。测试机是 4 核 8G 的普通云主机数据集 200 万条 IPv4 区间。方案内存占用单次查询100 万次查询总耗时Python 对象列表 线性扫描320MB约 40ms不可用Python 对象列表 二分310MB8µs9.2s平行整数数组 二分12MB1.6µs1.8s加进程内 LRU 缓存45MB0.3µs命中0.4s落 Redis/24 聚合独立进程0.15ms网络往返为主几个结论值得记一下。第一二分查找是必需品线性扫描在任何规模下都不可行。第二数据结构的影响比算法更大从对象列表换到平行数组性能提升五倍、内存降到 1/25改造成本却只有半天。第三缓存能再提一个数量级但要注意缓存穿透和失效策略。第四Redis 方案的延迟主要花在网络往返上如果你的查询量不大每秒几千次以内进程内缓存完全够用不必引入额外组件。还有一个容易被忽视的点启动加载时间。200 万条记录从 SQLite 读出来构建索引大约需要 8 秒。如果你的服务频繁重启比如容器化部署这 8 秒会很碍事。我的做法是把索引序列化成二进制文件用array.tobytes()启动时直接 mmap 读进来加载时间降到 0.6 秒。代价是数据更新后要重新生成这个文件纳入录入软件的收尾步骤就行。6.3 数据最小化与留存策略IP 地址在多数地区的实践中被视作个人相关信息这件事在设计和运营阶段就要考虑不要等出了问题再补救。我的做法是三条。第一能不存就不存完整 IP。风控和统计分析用 /24 前缀足够我在日志表里存的是前缀加一个加盐哈希需要精确定位原始 IP 时只能通过哈希比对不能反推。第二明确留存期限。访问日志里的 IP 字段保留 30 天超过就自动清空该列只留聚合后的地区统计。这个策略写进建表语句的注释里谁改表谁看见。第三流向透明。站点上有一页简短的说明讲清楚收集了什么、用来做什么、保留多久。这不是为了应付什么而是我自己作为用户也希望知道这些。技术上有个小技巧分区表 自动清理。日志表按月分区删除过期分区是一个元数据操作比DELETE FROM ... WHERE快几个数量级也不会产生大量碎片。CREATE TABLE access_log_202406 PARTITION OF access_log FOR VALUES FROM (2024-06-01) TO (2024-07-01); -- 到期直接 DROP秒级完成 DROP TABLE access_log_202406;这套东西配合录入软件的版本管理一起用整个链路就闭环了数据按月更新日志按月归档任何时候线上只有一份活跃数据加一份可回滚的备份。我在实际项目里最大的体会是IP 地理数据的价值不在于“准”而在于“可解释”。任何一条基于它做出的判断你都得能说清楚依据是什么、置信度多少、错了怎么回滚。我见过太多项目把地理位置当成一个黑盒开关命中就拦、不命中就放出问题的时候完全没法复盘。反而是一些看起来保守的做法——分级、降级、灰度、留日志——在长期运行中省下的时间远超它们增加的复杂度。最后分享一个小技巧给每一条地理规则都加一个“影子模式”规则照常计算但不执行只记录“如果执行会拦掉多少请求”。挂一周看看这个数字再决定要不要真的开。这个习惯让我避开了至少三次可能的大规模误杀。 
长河君 · 2026/10/31 9:10:43 · 阅读 1.2k IP地理数据批量录入与站点风控：二分索引和版本切换实践
1. 为什么要在自己的项目里养一份 IP 地理数据做数据录入软件这行久了会发现一个规律真正让人头疼的从来不是“录入”这个动作本身而是“录进来的数据准不准、用不用得上”。我这个项目的起点很朴素——标题里那套 IP 地理数据市面上有现成的接口也有现成的库但每次要接进自己的系统就得重新做一遍清洗、校验、落库、建索引做完还得担心数据过期。于是我把这套动作固化成一个小工具把 IP 地理数据批量录入本地库再用这份数据去保护站点、去自定义站点。它解决的是“IP 归属地数据从哪来、怎么存、怎么查得快、怎么用得稳”这一整条链路的问题。适合谁看如果你在做后台管理系统、内容站、电商站、API 网关或者你手里有一批访问日志需要做地域维度分析这套东西基本可以直接抄。前端同学可以只看第 5 章运维同学重点看第 3、4 章做数据管道的同学从头看。我不会假设你有很强的网络底层知识但我会假设你写过 SQL、跑过 Python 脚本知道 IP 地址长什么样。1.1 一个真实的需求场景站点被刷量之后的补救某公司的内容站有段时间被批量请求打得很惨日志里同一批 IP 段几分钟内换着路径扫注册接口被灌了几千条垃圾数据。最初的反应是加验证码结果正常用户的转化率掉了三成后来加频率限制又被分布式的请求绕过去了。真正让局面缓下来的一步是把访问日志里的 IP 拿出来做地域和网段维度的聚合——发现有相当比例的请求集中在少数几个数据中心网段归属地显示的城市跟站点实际用户分布完全对不上。按这个特征做了一层过滤垃圾请求的量级立刻降下来而正常用户几乎没有感知。这件事给我的启发是IP 地理数据不是拿来“展示”的是拿来“做判断”的。展示只是最表层的一步比如页脚显示“来自某地”。真正有价值的是把它变成一条条可以执行的规则这个网段属于机房还是家庭宽带这个地区的访问频次是否异常这个用户所在时区该给他看哪个版本的时间戳这些判断的前提都是你手里有一份结构规整、可以随手查询的 IP 地理库。而这份库从哪来这就是录入软件要干的事。它不是一个炫技的项目本质是一条数据流水线拉取、清洗、校验、入库、建索引、切换版本。听起来枯燥但每一步都有坑坑的位置还特别固定。1.2 整体架构录入软件在链路中的位置我把整个系统拆成四层从下往上说。数据源层负责提供原始 IP 地理数据常见形态有三种按网段切分的 CSV、二进制格式的库文件、以及按单个 IP 查询的在线接口。三者的精度、更新频率、体积差别很大后面 1.3 会细说。录入层就是我说的这个数据录入软件它做五件事格式识别、字段映射、合法性校验、去重合并、分批落库。这一层是整条链路里最容易被低估的部分因为脏数据几乎必然存在——国家名写成两种语言、城市名带不可见字符、网段起止写反、IPv6 混进 IPv4 表里。不在这里拦住后面查询层就得天天背锅。存储层是自建的数据库我选了“整数区间 二分查找”的模型理由在 2.1 展开。这个模型的好处是查询极快、改造灵活坏处是需要自己维护索引和版本。应用层分两条支线一条通往“保护站点”也就是风控规则引擎另一条通往“自定义站点”也就是多语言、多币种、时区、内容差异化。两条支线共用同一个查询接口但缓存策略完全不同——风控要的是实时和准确个性化要的是低延迟和高命中。四层之间我用一个约定隔开录入层只负责把数据变干净不做任何业务判断应用层只消费查询接口不直接碰库。这个约定听起来像教条但它救过我一次——某次数据源格式大改我只改了录入层的字段映射应用层一行代码没动就平滑过渡了。反过来如果业务逻辑里到处散落着“读 CSV 第 7 列”那次改版至少要拖两周。1.3 在线接口与离线库的取舍我为什么两个都要这是被问得最多的一个问题既然有在线接口为什么还要费劲自己建库先看在线接口。它的优势很明确单次查询就能拿到结构化结果字段通常比较全包含国家、省州、城市、经纬度、时区、运营商、是否是数据中心网段等维护成本几乎为零不用操心数据更新。缺点同样突出有网络依赖、有配额限制、有延迟成本。站点每天的访问量到十万级的时候如果每个请求都同步调一次外部接口页面首字节时间会被硬生生拉长几十毫秒接口一抖动整个站点跟着抖。这还没算上配额——批量回补历史日志的时候几十万条 IP 一次跑完很容易把当天额度打空。离线库反过来查询是本地内存操作微秒级没有配额概念想查多少查多少数据落在自己手里隐私上更可控。代价是要自己维护更新而且原始数据的精度和字段完整度通常不如商业接口。所以我的做法是分层使用主链路每个请求都要判定的场景走离线库保证延迟可控旁路离线分析、日志回补、疑难 IP 复核走在线接口拿更细的字段做补充。两边通过一个统一的查询函数封装起来业务侧只看到lookup(ip)不关心底层走的是哪条路。这个设计还有一个隐性好处在线接口返回的结果可以做抽样比对用来监控离线库的准确率。我设了一个每天 200 条的抽样比对任务偏差率超过阈值就告警——这个机制后来帮我发现过一次数据源更新滞后的问题。有一点要提醒不要把在线接口当成“绝对正确”的参照物。地理定位本质上是概率推断同一个人用手机在两地之间通勤上午查是一个城市下午查是另一个城市这不是谁的错。做规则的时候一定要给“不确定”留出位置具体在 4.3 讲。2. 数据录入软件的设计与字段规范2.1 表结构怎么定把 IP 段存成整数区间先说结论不要用字符串存 IP也不要用字符串比较做范围查询。IPv4 地址本质是一个 32 位无符号整数192.168.1.1转成整数就是3232235777。把网段存成(start_int, end_int)这样的闭区间查询就退化成一次“给定数字找包含它的区间”的问题用二分查找在有序数组上做复杂度 O(log n)。字符串方案的问题在于9.1.1.1 10.1.1.1是成立的按字典序但数值上 9 开头的地址小于 10 开头的地址排序全乱范围查询直接失效。表结构我用了两张表一张存区间一张存地理实体靠 ID 关联CREATE TABLE geo_entity ( geo_id INTEGER PRIMARY KEY, country_code CHAR(2) NOT NULL, country_name VARCHAR(64), region_name VARCHAR(128), city_name VARCHAR(128), timezone VARCHAR(64), latitude REAL, longitude REAL, is_datacenter SMALLINT DEFAULT 0 ); CREATE TABLE ip_range_v4 ( start_int INTEGER NOT NULL, end_int INTEGER NOT NULL, geo_id INTEGER NOT NULL, confidence SMALLINT DEFAULT 0, version INTEGER NOT NULL ); CREATE INDEX idx_range_v4 ON ip_range_v4(version, start_int, end_int);为什么拆两张表因为地理实体的重复度极高——同一个城市可能对应几千个网段如果每行都存一遍城市名和时区表体积会膨胀好几倍更新一个城市名还得扫全表。拆开之后区间表只存三个整数紧凑得很。实测下来200 万条区间记录在 SQLite 里占的空间大约 90MB拆表之前是 340MB差了将近四倍。confidence字段是给自己留的后路。不同数据源对“这个网段定位到城市”的置信度不一样我统一映射成 0-100 的分数国家级别 30省州级别 60城市级别 85有运营商或建筑级信息的 95。风控规则里会用到这个分数——低置信度的记录只用来做粗筛不参与封禁类决策。version是版本号配合 3.3 的滚动切换。这一列看着多余实际上是整个录入软件能“不停服更新”的关键。IPv6 单独建表结构一样但用 TEXT 存 128 位地址的前缀。这块数据量小得多我暂时没做深度优化够用就行。2.2 数据源清洗把五花八门的格式拉齐原始数据到手的第一个小时基本都在跟格式搏斗。我踩过的典型情况整理成一张表方便你对照现象典型表现处理方式网段起止写反start end交换两值并记一条告警日志网段重叠两条记录区间有交集保留 confidence 高的另一条裁剪CIDR 混入区间表出现1.2.3.0/24解析成起止整数再入表城市名带不可见字符尾部有\u200b或多余空格统一 strip 正则过滤控制字符国家名中英混杂同一国家两种写法建映射字典落到 ISO 两位码时区写成偏移量08:00转成 IANA 时区名如Asia/ShanghaiIPv6 混进 v4 表点分十进制解析报错按冒号数量分流到不同解析分支空值与占位符-、N/A、null统一转 NULL不参与城市级判定这张表里最坑的是“网段重叠”。理论上 IP 段不应该重叠现实中不同批次的数据合并时经常出现因为数据源更新时旧段没删干净。如果不处理二分查找会命中哪个区间完全看运气同一个 IP 两次查询结果不一样排查起来能让人怀疑人生。我的处理是入表前做一次全局排序 扫描合并遇到重叠就按置信度取舍同时把冲突记录写进一张conflict_log表方便回溯是哪一批数据引入的。另一个容易被忽略的是编码问题。某些数据源的城市名用本地语言写文件头却声明 UTF-8读进来是一堆问号。我的做法是读取时先按字节嗅探UTF-8 失败就退到 GBK 尝试两个都失败就整行跳过并计数。跳过率超过 0.5% 就停止导入——这通常意味着文件整体不是你以为的那个格式硬着头皮录进去只会污染库。提示清洗阶段一定要保留“原始行号”。出了问题时你能靠行号快速定位到源文件的哪一行比只知道“有 3 条数据异常”有用得多。2.3 录入流程分批、事务、断点续跑录入这件事小数据量怎么都好说上了百万行就必须考虑三件事内存、事务、中断。内存不要一次性把整个文件读进列表再处理。我一开始就是这么干的40 万行的 CSV 读进内存后Python 进程占了 1.2GB机器直接开始换页。改成流式迭代后峰值内存压到 200MB 以内。具体做法是生成器逐行 yield每攒够一批就落库并清空缓冲。事务每行一个事务是最慢的做法磁盘 fsync 次数太多。我按批提交一批 5000 行。这个数字不是拍脑袋来的——我试过 500、1000、5000、20000 四档在本地 SSD 上录入 40 万行的耗时分别是 62s、38s、21s、23s。5000 行是拐点再往上收益递减而单次事务失败要回滚的数据量却变大得不偿失。断点续跑录入过程中机器重启、脚本被杀、数据库连接超时都是常事。我加了一个import_progress表记录“哪个文件、处理到第几行、本批次是否已提交”。重跑时从断点继续不会重复插入。这里有个细节进度记录必须在事务提交之后写顺序反了会出现“进度记了但数据没进去”的空洞比重复插入更难查。整个流水线的伪代码大概长这样def import_file(path, batch_size5000): buf [] for lineno, row in enumerate(stream_rows(path), start1): rec normalize(row, lineno) # 清洗 校验 if rec is None: skipped 1 continue buf.append(rec) if len(buf) batch_size: commit_batch(buf) # 单事务写入 save_progress(path, lineno) # 事务提交后再记进度 buf.clear() if buf: commit_batch(buf) save_progress(path, lineno)commit_batch里我用的是executemany而不是拼 SQL 字符串除了防注入还有个现实原因拼出来的超长 SQL 在某些驱动上会撞到语句长度上限报错信息还特别模糊。3. 核心实现录入与查询的代码骨架3.1 批量录入脚本5000 行一批的理由接着上面的批次大小说。除了耗时还有一个因素决定批次大小锁的粒度。如果录入和查询共用同一个数据库一批写入时间太长会阻塞查询。5000 行在 SQLite 上的写入耗时大概 0.25 秒这个量级的锁等待对线上查询基本无感换成 20000 行一批单次写入 0.9 秒查询侧就会出现明显的毛刺。SQLite 我还调了几个参数效果比想象中大PRAGMA journal_mode WAL; -- 读写不互斥 PRAGMA synchronous NORMAL; -- 牺牲极端断电安全换速度 PRAGMA cache_size -64000; -- 64MB 页缓存 PRAGMA temp_store MEMORY; -- 临时表放内存journal_modeWAL是最关键的一条它让读操作不被写操作阻塞。改之前录入期间查询延迟能飙到 800ms改之后基本维持在 20ms 以内。synchronousNORMAL意味着极端断电情况下可能丢最后一个事务对 IP 地理数据这种可以重跑的场景完全可以接受——但如果是订单类数据请老老实实保持 FULL。如果你用的是 PostgreSQL思路类似但手段不同COPY命令比INSERT快一个数量级40 万行用COPY FROM STDIN大概 6 秒索引建议先删后建录完再CREATE INDEX比边插边维护索引快两三倍。这个技巧在大批量回补历史数据时特别好用。3.2 查询层二分查找与缓存查询的核心是“给定 IP 整数找出包含它的区间”。数据按start_int升序排列后用二分找到最后一个start_int ip的位置再检查该位置的end_int ip即可。import bisect class RangeIndex: def __init__(self, rows): rows.sort(keylambda r: r[0]) self.starts [r[0] for r in rows] self.ends [r[1] for r in rows] self.geo [r[2] for r in rows] self.conf [r[3] for r in rows] def lookup(self, ip_int): i bisect.bisect_right(self.starts, ip_int) - 1 if i 0 and self.ends[i] ip_int: return self.geo[i], self.conf[i] return None, 0把starts、ends、geo拆成三个平行数组列式存储比存对象列表快很多。原因是 Python 对象有额外开销遍历时缓存不友好。我实测过100 万条记录对象列表每次查询约 8 微秒平行数组约 1.6 微秒差了五倍。内存占用差距更大——对象列表 300MB 以上三个整数数组用array模块存是 12MB 左右。缓存分两层。第一层是进程内 LRU缓存最近查询的 10 万个 IP命中率在真实流量下大概 60%-75%。第二层是 IP 段聚合把 IP 的前 24 位IPv4 的 /24 网段作为缓存 key而不是完整 IP。这个改动把缓存命中率从 70% 提到了 92%因为同一网段的用户大概率落在同一个地理区域。代价是精度损失——一个 /24 里的 256 个地址被当成同一个位置实际误差最多到区县级用于个性化完全够用用于风控则需要谨慎4.3 会讲怎么处理。缓存还有一个坑不要缓存“查不到”的结果。未收录的 IP 查出来是 None如果这个 None 进了缓存等数据更新后依然返回 None看起来像数据没生效。我的做法是未命中结果只缓存 5 分钟命中结果缓存 1 小时。3.3 增量更新与版本切换不锁表IP 地理数据每月都在变更新必须有但不能停服。我用的是“影子表 版本号”方案。新建一张ip_range_v4_new把新数据全部录进去建好索引。校验通过行数、覆盖率、抽查比对都过之后在一个事务里做三件事更新一个配置表里的active_version把旧版本标记为待清理提交。查询层每次查询时读取active_version这个值缓存在内存里5 秒刷新一次带上版本号去查。这个方案的妙处在于没有任何锁表操作旧数据在新版本生效的那一刻起才不可见之前的所有查询都正常返回。清理旧版本可以延迟到低峰期做甚至保留两个版本以支持快速回滚。BEGIN; UPDATE config SET value 202406 WHERE key active_version; COMMIT; -- 低峰期执行 DELETE FROM ip_range_v4 WHERE version 202405;要注意的是active_version的读取频率。如果每个请求都去查一次配置表数据库压力不小。我把它放在进程内存里5 秒同步一次切换的延迟就是 5 秒。对 IP 地理数据这种更新频率来说5 秒的生效延迟完全无所谓。还有一个细节新版本上线前必须做覆盖率对比。我用同一批 1 万个抽样 IP分别用新旧版本查询统计“结果一致率”和“从有结果变成无结果”的比例。后者如果超过 1%说明新数据源有问题宁可不上也不要上。这个检查帮我拦住过一次数据源裁剪失误——新版本漏了整整一个大洲的网段。4. 用地理位置数据保护站点把风险挡在业务之前4.1 分层风控先把流量的“来路”分级“保护站点”这个说法容易被理解成上一套防火墙其实不是。IP 地理数据在防护里的作用是给每个请求补充一个“来路画像”让后续规则有依据。我的分级是这样的等级判定依据处理策略L0 可信家庭宽带网段 高置信度城市 历史行为正常全量放行不做额外校验L1 正常普通网段置信度中等正常处理只记录L2 存疑数据中心网段或归属地与声明地区严重不符加轻量校验如限频、要求完成一次交互L3 高危数据中心网段 高频 短时间多账号行为拦截或转人工审核这里要强调等级不是判决是优先级。L3 不等于“一定是坏人”只是“值得多看一眼”。把 L3 直接等同于封禁是误杀的主要来源具体见 4.3。分级依据里“数据中心网段”这个字段特别有用。它来自数据源的标注标识某个网段属于云服务商或机房而非住宅宽带。正常用户的家庭网络几乎不会落在这类网段里而批量请求工具往往跑在云主机上。这个特征单独用误判率不低有些企业办公网也走机房出口但叠加上频次和行为特征之后判别力就很强了。4.2 规则落地的三种形态边缘、应用、异步同一个判断放在不同的位置执行效果差别很大。边缘层反向代理或 CDN 边缘适合做粗粒度的拦截整段网段拒绝、按国家或地区做访问范围控制、简单的频率阈值。优势是请求根本进不到应用服务器成本最低劣势是规则变更需要重载配置而且边缘能拿到的上下文有限。Nginx 的geo模块可以加载网段列表做映射配置大概是这样geo $risk_level { default 1; include /etc/nginx/geo/datacenter_ranges.txt; # 值映射到 3 10.0.0.0/8 0; # 内网段直接放行 } map $risk_level $limit_key { 3 $binary_remote_addr; default ; } limit_req_zone $limit_key zonerisky:10m rate5r/s;limit_req_zone的 key 为空时不生效这个技巧让我只对高风险等级做限流正常流量完全不受影响。这种“按条件启用限流”的写法在文档里不显眼但实战中极其有用。应用层适合做带业务上下文的判断登录接口按地区做二次验证、注册接口限制同一网段的账号创建速率、支付接口校验账单地区与访问地区的一致性。应用层能拿到用户 ID、设备指纹、历史行为判断更准代价是消耗服务器资源。异步层适合做回溯分析把请求日志带上地理字段落盘离线跑聚合任务发现异常模式后再反哺前两层。异步层不影响实时性能是最安全的试验田。我的很多规则都是先在异步层跑一周看误报率确认没问题再往边缘层搬。三层之间要有清晰的职责边界否则会出现“同一个 IP 在边缘被拦、在应用层被放行”的混乱。我的约定是边缘层只做“明显不该来”的拦截应用层做“可能需要确认”的校验异步层只观察不干预。4.3 误杀控制白名单、灰度与申诉通道这一段是整章最重要的因为防护系统最大的风险不是漏放是误杀。第一不确定就降级。查询返回的confidence低于 60 时不要用它做拦截决策最多用来调整限频阈值。数据库里查不到的 IP一律按 L1 处理不因为“未知”就判为高危。未知 IP 的量在真实流量里通常占 3%-8%全部按高危处理误杀率会高得离谱。第二白名单要分层。我设了三层全局白名单内部服务、合作方固定出口、业务白名单某个业务线自己的合作渠道、临时白名单运营手工加的带过期时间。第三层最容易被滥用所以强制要求填过期时间最长 7 天过期自动失效。第三灰度放量。任何新规则上线先只对 5% 的流量生效观察 24 小时。观察指标不是“拦截了多少”而是“误杀申诉量”和“正常业务指标有没有波动”。这两个指标里后者更重要——很多误杀用户根本不会申诉直接走了。第四给不确定的流量一个出口。对 L2 存疑流量我不用直接拦截而是要求完成一次轻量交互比如页面停留超过 2 秒、完成一个简单的滑块。这类交互对真人几乎无感对批量脚本是硬门槛。注意任何基于地理位置数据的拦截规则都必须能解释“为什么拦”。我在规则配置里强制要求填reason字段出问题时能一眼看出是哪条规则命中。没有 reason 的规则不允许上线这条规矩救过我好几次。4.4 一套可以直接抄的判定流程把上面的东西串起来单个请求的判定大概是这样走的def assess(ip, ua, path, recent): geo, conf index.lookup(ip_to_int(ip)) if geo is None: return L1, geo_miss if ip in global_whitelist: return L0, whitelist if geo.is_datacenter and conf 85: if recent.hits_1min 30 and recent.distinct_paths 10: return L3, dc_scan return L2, dc_low_conf if path.startswith(/api/) and conf 60: return L2, low_conf_api return L1, default这段代码没什么花哨的地方但每条分支背后都对应一次线上事故的教训。distinct_paths这个条件就是后来加的——只看请求数会把正常的高频轮询接口误判加上“路径分散度”才准确。5. 用地理位置数据自定义站点体验层面的收益5.1 语言、货币、时区三件套“自定义站点”听着像是要做一套复杂的推荐系统其实收益最大的三件事特别朴素语言、货币、时区。语言按 IP 归属地给一个默认语言但一定要允许用户手动切换并且切换后记住选择。用户的手动选择优先级永远高于 IP 推断。我见过太多站点犯这个错用户切到英文刷新页面又变回中文只因为 IP 在国内。这个体验损伤比不自动切换还严重。货币电商站按地区展示默认货币价格换算要小心。不要用实时汇率直接乘把换算后的价格缓存一段时间我用 15 分钟否则同一件商品两次刷新价格不一样用户会觉得你不靠谱。另外某些地区的价格敏感度差异很大直接按汇率换算常常不合适这块需要业务侧自己定技术侧只提供“地区”这个输入。时区这个最容易做收益也最直接。订单时间、活动开始时间、日志时间戳全部按用户所在时区渲染。实现上不需要 IP 数据也能做——浏览器能拿到时区——但当用户还没执行 JS 时比如邮件、服务端渲染的首屏IP 数据就是唯一的来源。所以我的做法是服务端用 IP 推断给初始值客户端 JS 拿到真实时区后覆盖并上报。两者不一致时以客户端为准同时记一条日志用于监控 IP 库的准确率。这三件事的投入产出比极高加起来不到一天工作量用户感知却很明显。相比之下花两周做的“个性化推荐”在流量不大的站点上往往看不到效果。5.2 缓存与 Vary 头最容易翻车的地方按 IP 判断地区来做内容差异化最容易踩的坑是缓存串味。假设你的页面按地区展示不同的推荐内容CDN 把第一个访问者的页面缓存下来后面所有人都看到同一个版本。这在测试环境完全发现不了上线后就是一场灾难。解决思路有两条。第一条是把地区编码进缓存 keyCDN 层面按国家或地区分缓存例如/page?regioncn。这条路的优点是简单直接缺点是缓存命中率下降——分成 20 个地区就是 20 份缓存每份都要单独回源。我的做法是只对国家维度分缓存通常不超过 10 个有效国家更细的城市级差异化放到客户端做。第二条是用 Vary 头。如果你按Accept-Language做内容协商必须加上Vary: Accept-Language否则缓存会把中文页面返回给英文用户。但要注意Vary加得越多缓存命中率越低因为每个维度组合都是独立的缓存条目。Vary: Accept-Language, Accept-Encoding Cache-Control: public, max-age300, s-maxage600第二条路看起来更“标准”但实测下来我倾向于第一条——显式编码在 URL 里排查问题的时候一眼就能看出这个缓存属于哪个地区比翻 Vary 头快得多。还有一个细节不要在服务端根据 IP 做重定向来切换语言。比如检测到日本 IP 就 302 到/ja/。这个方案对搜索引擎极不友好爬虫的 IP 可能在任何地方抓到的内容和用户看到的对不上。正确做法是在同一 URL 下返回不同语言的内容用hreflang标注或者在客户端做切换。5.3 内容差异化与 A/B 的边界再往上一层就是内容差异化不同地区展示不同的活动、不同的商品排序、不同的推荐位。这块我的建议是先用数据说话再动手做。拿历史访问日志跑一遍地理维度的聚合看不同地区的用户行为到底差多少。我做过一次分析发现两个地区的用户点击分布相似度高达 90%那这种情况下做地区差异化纯属浪费人力。反过来另一个案例里某两个地区的支付方式偏好差异巨大那这个差异化就非常值得做。A/B 实验和地理定位结合的时候有个陷阱分流必须按用户 ID 哈希不能按 IP。按 IP 分流会导致同一个用户换个网络就看到另一个版本实验数据全废。IP 数据在这里的正确用法是“作为分层维度”——比如你想知道新方案在某个地区效果如何就在实验分析时按地区切分数据而不是按地区分配实验组。另外一个必须说的边界差异化不等于歧视。同一个服务不同地区的用户应该享受到同等的核心功能差异化的只能是表现形式语言、货币、内容排序和运营策略。这条线要划清楚否则技术上的“优化”很容易变成业务上的问题。6. 常见问题与排查技巧实录6.1 定位不准的六种典型表现“这个 IP 查出来的位置不对”——这是我收到最多的反馈。实际情况千差万别我整理成一张速查表现象根因处置方式城市对了区县错了数据源本身只到城市级降低该字段置信度不用于精细判定移动网络定位漂移运营商出口节点与用户实际位置不同移动网段只信到省州级企业专线定位到总部出口 IP 属于总部机房结合 ASN 字段判断企业网段放宽同一 IP 结果前后不一缓存穿透或版本切换中检查 active_version 同步间隔新分配 IP 查不到数据源更新滞后未命中走在线接口兜底IPv6 全部命中不到表没建或前缀长度不匹配单独校验 IPv6 分支这里面最值得展开的是移动网络定位漂移。移动用户的 IP 常常是运营商核心网出口一个出口后面挂着几十万用户地理位置可能对应到省会城市而不是用户所在的三线城市。如果你的业务需要城市级精度比如本地生活服务必须接受“移动网络只能给到省级”这个现实用其他信号GPS、用户填写地址来补充。硬要拿 IP 做城市级判定错误率会让你怀疑数据质量。企业专线的情况类似。某公司的出口 IP 注册在总部所在地但员工可能分布在十几个城市。这类网段的地理字段对“人在哪”判断力很弱但对“这人属于哪个组织”判断力很强——如果能拿到 ASN自治系统号或组织名称字段用组织维度做判断会准得多。6.2 性能与内存几条实测数据性能这块我做过一轮压测数据放在这里供参考。测试机是 4 核 8G 的普通云主机数据集 200 万条 IPv4 区间。方案内存占用单次查询100 万次查询总耗时Python 对象列表 线性扫描320MB约 40ms不可用Python 对象列表 二分310MB8µs9.2s平行整数数组 二分12MB1.6µs1.8s加进程内 LRU 缓存45MB0.3µs命中0.4s落 Redis/24 聚合独立进程0.15ms网络往返为主几个结论值得记一下。第一二分查找是必需品线性扫描在任何规模下都不可行。第二数据结构的影响比算法更大从对象列表换到平行数组性能提升五倍、内存降到 1/25改造成本却只有半天。第三缓存能再提一个数量级但要注意缓存穿透和失效策略。第四Redis 方案的延迟主要花在网络往返上如果你的查询量不大每秒几千次以内进程内缓存完全够用不必引入额外组件。还有一个容易被忽视的点启动加载时间。200 万条记录从 SQLite 读出来构建索引大约需要 8 秒。如果你的服务频繁重启比如容器化部署这 8 秒会很碍事。我的做法是把索引序列化成二进制文件用array.tobytes()启动时直接 mmap 读进来加载时间降到 0.6 秒。代价是数据更新后要重新生成这个文件纳入录入软件的收尾步骤就行。6.3 数据最小化与留存策略IP 地址在多数地区的实践中被视作个人相关信息这件事在设计和运营阶段就要考虑不要等出了问题再补救。我的做法是三条。第一能不存就不存完整 IP。风控和统计分析用 /24 前缀足够我在日志表里存的是前缀加一个加盐哈希需要精确定位原始 IP 时只能通过哈希比对不能反推。第二明确留存期限。访问日志里的 IP 字段保留 30 天超过就自动清空该列只留聚合后的地区统计。这个策略写进建表语句的注释里谁改表谁看见。第三流向透明。站点上有一页简短的说明讲清楚收集了什么、用来做什么、保留多久。这不是为了应付什么而是我自己作为用户也希望知道这些。技术上有个小技巧分区表 自动清理。日志表按月分区删除过期分区是一个元数据操作比DELETE FROM ... WHERE快几个数量级也不会产生大量碎片。CREATE TABLE access_log_202406 PARTITION OF access_log FOR VALUES FROM (2024-06-01) TO (2024-07-01); -- 到期直接 DROP秒级完成 DROP TABLE access_log_202406;这套东西配合录入软件的版本管理一起用整个链路就闭环了数据按月更新日志按月归档任何时候线上只有一份活跃数据加一份可回滚的备份。我在实际项目里最大的体会是IP 地理数据的价值不在于“准”而在于“可解释”。任何一条基于它做出的判断你都得能说清楚依据是什么、置信度多少、错了怎么回滚。我见过太多项目把地理位置当成一个黑盒开关命中就拦、不命中就放出问题的时候完全没法复盘。反而是一些看起来保守的做法——分级、降级、灰度、留日志——在长期运行中省下的时间远超它们增加的复杂度。最后分享一个小技巧给每一条地理规则都加一个“影子模式”规则照常计算但不执行只记录“如果执行会拦掉多少请求”。挂一周看看这个数字再决定要不要真的开。这个习惯让我避开了至少三次可能的大规模误杀。