4551个关键词连续三轮100%成功的百度批量排名查询优化实战

这次优化面对的是一个很具体的生产问题。4551 个关键词批量查询百度前 50 条结果，旧任务虽然最终可以补齐全部关键词，却要跑 40 分 37 秒，首轮留下 1323 个失败页，随后又补跑 5 轮。目标被定为单轮查询成功率 100%，总用时不超过 20 分钟，而且必须连续 3 轮同时达标。

最终三轮分别用了 11 分 40 秒、11 分 29 秒和 15 分 8 秒，4551 个关键词每轮都查询成功，失败数均为 0。三轮共解析并保存 594547 条原始搜索结果。第三轮遇到的网络波动更大，仍然留出了接近 5 分钟的余量，这比一次偶然跑进 20 分钟更有说服力。

一、起点为什么会跑到 40 分钟

旧任务从 10 时 33 分 46 秒开始，到 11 时 14 分 23 秒结束。4551 个关键词最终都拿到了结果，表面上看成功率没有问题，可首轮只有 3228 页成功，1323 页需要补跑。系统连续补了 5 轮才把缺口填完，平均速度约为每分钟 112 个关键词。

把日志按阶段拆开后，时间主要消耗在四处。

• 大量代理只能打开供应商接口，却无法稳定打开百度搜索页。每个坏代理进入业务队列后，都会吃掉一次完整超时。
• 每次请求都重新建立客户端，成功代理积累下来的 Cookie、连接和浏览器特征随即丢失。
• 验证码、连接失败和响应超时混在同一类失败里，曾经成功的代理也会被过早淘汰，调度器不断回到质量未知的候选池。
• 约 20 万条原始结果等查询全部完成后才集中写库，单是收尾就接近 2 分钟。

继续加并发只会更快耗尽代理。无效等待、重复握手、错误重试和串行写库组成了主要耗时，接下来的改动都围绕这四处展开。

二、先固定成功口径，防止数字好看而数据失真

批量查询最容易出现一种假优化。程序把超时页当成空结果，或沿用旧任务的数据，成功率会立刻变成 100%，速度也会很好看，但这样的记录无法用于排名判断。

本次验收给成功设置了硬边界。

1. 每个关键词都必须真实请求百度桌面搜索页。
2. 页面中解析到有效自然结果卡片，才能记录标题、目标地址、域名和位次。
3. 只有页面明确出现零结果特征时，空结果才算查询成功。
4. 验证码页、小体积软拦截页、模板异常页和连接错误都算失败，必须更换代理后重试。
5. 不复用旧排名数据，不删除难查关键词，不用移动端结果填补桌面端缺口。

最终报告里的 4551 比 4551，表示 4551 个关键词都通过了这套真实解析判定。它与有多少业务网站进入前 50 名是两个指标，不能混为一谈。

三、先验证一次拿 50 条的接口设想

优化初期曾考虑使用 tn=json。如果它能稳定返回结构化数据，解析成本会更低，也可以省去 HTML 版式适配。

受控试验给出的结果很明确。一批 593 条候选代理经过首页验证后剩下 49 条，其中 39 条进入接口试验。JSON 成功数为 0，35 条直接进入约 1488 字节的安全验证页，另外 4 条发生网络错误。另一路桌面 HTML 搜索仍有 13 条可以解析。

这说明在当时的代理出口和百度风控条件下，tn=json 的可用率远低于桌面 HTML。继续围绕它调参数，只会把可工作的代理也送进验证码。主查询方式因此确定为桌面搜索参数 tn=baiduhome_pg、rn=50 和 pn=0。每个关键词只发一次搜索请求，最多解析 50 条结果。

四、为什么取消移动端降级

移动端单页通常只能稳定拿到约 10 条结果。为了覆盖前 50 名，一个关键词要连续请求 5 个子页。4551 个关键词会由约 4551 次业务请求膨胀到约 22755 次，还会产生子页缺失、位次拼接和中途验证码等新问题。

实测中，移动端降级把代理消耗速度放大得很明显。某轮运行 3 小时只处理了 849 个关键词，已经偏离 20 分钟目标。最终关闭移动端查询和验证码降级，只接受桌面结果。桌面模板异常时让关键词进入补跑，避免用不完整的五页拼接结果冒充成功。

五、代理预检要回答两个不同的问题

代理供应商标记有效，只能说明代理节点在供应商检测时存活。排名任务还需要知道它能否访问百度首页，以及能否在更大的搜索结果页上完成 TLS 建连、下载和解析。

预检因此分为两层。

• 百度首页验活 超时放宽到 6 秒，用高并发快速剔除完全无法连接的节点。
• 搜索页探测 超时设为 8 秒，使用与正式查询相同的桌面页面和解析器。通过者进入热代理池，其余首页可用节点保留为温代理储备。

短超时曾造成严重误杀。一次测试中，2.5 秒门槛只留下约 70 至 84 条代理；改成 6 秒后，776 条候选里有 207 条通过首页验证。那些响应稍慢但能稳定查询的长存活代理，正是大任务后半程需要的储备。

代理源返回后先按地区和存活时间排序。中国长存活代理最先进入验证队列，随后是国外长存活代理，国家未知的节点排在最后。同一网关的不同端口不能只按主机名去重。出口回显试验证实，部分网关的不同端口对应不同公网出口，误合并会白白丢掉容量。

六、会话复用怎样保住成功代理

一个代理刚刚成功完成搜索，已经证明当前出口、连接、Cookie 和页面路径都可用。旧逻辑却在下一关键词重新创建客户端，等于主动放弃这份确定性。

改造后，每个代理绑定一个长期 HTTP Session。这个 Session 固定浏览器身份和 TLS 特征，保留 Cookie，并尽量复用已建立的连接。工作线程还会记住自己最近成功的代理。短暂冷却结束后，只要代理仍健康，就继续用同一个会话查询下一个关键词。发生验证码或明确连接故障时才切换。

会话随后扩展为跨任务缓存。上一轮成功过的 Session 最多保留 1000 个，下一轮可以直接接着使用。连续三轮验证时，第二轮和第三轮不必从完全陌生的连接状态起步，这也是多轮表现能够稳定的重要原因。

会话复用还有一条容易忽略的约束。同一代理不能在几秒内不断变换 User-Agent、Cookie 和 TLS 指纹。搜索引擎看到同一个出口突然表现成多台设备，验证码概率会快速升高。固定会话让请求行为更接近一个连续使用的浏览器。

七、并发、节奏和隔离时间要一起调整

全局并发最终设为 48，单 IP 并发设为 3。单 IP 每分钟最多调度 60 次，成功会话在两次继续使用之间至少间隔 1.5 秒。验证码代理隔离 300 秒。

这些数字来自多轮对照测试。单 IP 并发 1 时，代理很稳，但总吞吐无法稳定进入 20 分钟。单 IP 并发 2 已经接近目标，波动较大的轮次仍会剩下 11 至 60 个失败页。单 IP 并发 3 配合 1.5 秒节奏后，48 个工作线程可以充分利用健康会话，又没有把请求瞬间压到少数热代理上。

早期曾使用 0.5 秒间隔，并给验证码设置较短冷却。结果是一个已触发风控的代理很快重新回到队列，同一验证码页被反复请求，重试机会不断被消耗。把隔离时间延长到 300 秒后，任务会把流量移交给其他健康代理，受限出口留到更晚再恢复。

失败分类也随之细化。明确无法连接且从未成功过的代理，本轮直接判为失效。曾经成功的代理遇到超时、连接重置或验证码，只降分并进入对应冷却，不会清空累计成功次数。这样既能让坏代理尽快退出，也能防止一次瞬时抖动误杀好代理。

八、每 60 秒补代理时，只处理真正新增的地址

运行中补充代理是必要的，但全池重复验活代价很高。旧方案每 60 秒把整个代理源再测一遍，单次会附加数百个百度请求，并让主任务暂停约 27 秒。重复测试还会提前消耗已经健康的出口。

新的补血循环保留一份已见地址集合。每 60 秒重新读取原始代理源，只领取新出现的 IP 和端口。新增节点先做首页验证，通过后加入温代理池，后续再通过真实搜索晋升为热代理。已有 Session、Cookie、评分、冷却时间和工作线程绑定关系全部保留。

这项改动也解决了代理池看似枯竭的问题。界面上的可用数为 0，有时只是健康代理正在请求或处于 1.5 秒短冷却。调度器会先等待已有会话恢复，同时让新增代理在后台补入，不会立即清空池子并重载所有旧节点。

九、查询和写库必须重叠进行

一次完整任务大约产生 19.7 万至 19.9 万条原始结果。旧流程把它们全部留在内存，网络查询结束后才开始批量插入数据库。一次 168054 行的实测写入用了 1 分 59 秒。即使查询在 18 分钟结束，最终页面也要到 20 分钟后才能看到完成状态。

改造后增加后台原始结果写入器。关键词解析成功后，结果立即进入内存队列；后台以最多 20000 行为一批持续写库。网络线程继续查询下一批关键词，数据库写入同时推进。任务收尾只需等待最后一个不足批次提交，通常剩下约 8 至 11 秒。

写入器仍然遵守任务级一致性。开跑前清理当前任务自己的残留记录，每个批次只写当前任务 ID，结束时等待队列排空并提交事务。排名命中计算沿用原有规则，没有用写入速度换取数据口径变化。

十、给 20 分钟目标留出可控的时间边界

任务内部查询预算最终设为 1170 秒，也就是 19 分 30 秒。剩余 30 秒留给在途请求结束、后台写入器排空、命中计算和任务状态落库。每个关键词开始前和每次补跑前都会检查截止时间，避免最后几个失败页把整轮拖得没有上限。

只设硬截止仍然不够。系统还会记录首轮成功数、失败原因分布、可用代理状态、补跑进展和剩余预算。若连续补跑没有进展，调度器会等待代理冷却或新增节点，而非用几十轮空转把时间耗尽。

十一、几次关键失败教会了什么

参数调优过程中出现过几轮很接近目标的结果。它们比成功轮更能说明系统的边界。

还有一个运维层面的坑。进程管理器曾因默认内存阈值重启后端，旧子进程没有及时退出，两个实例同时争用任务锁和数据库连接。最终把内存上限调整到与大批量任务匹配，并在重启后核对服务端口只对应一个进程。批量抓取的正确性不仅取决于请求代码，也取决于运行时是否保持单实例。

十二、最终参数清单

十三、最终调度流程

读取私有代理源并按地区、存活时间排序
并发执行 6 秒百度首页验活
对候选节点执行 8 秒桌面搜索页探测
将探测成功者放入热池，首页成功者放入温池

启动 48 个关键词工作线程
每个线程优先续用最近成功的代理 Session
同一 IP 最多同时处理 3 个请求
成功后等待 1.5 秒再复用
验证码出现后隔离对应 IP 300 秒
每 60 秒只领取并验证代理源新增地址

解析成功后立即把原始结果送入后台写库队列
写库器累计到 20000 行就提交一个批次
查询与写库并行推进

在 1170 秒查询预算内补跑真实失败页
等待写库队列排空并计算排名命中
只有全部关键词完成真实解析才把任务标记为成功

十四、连续三轮验收结果

三轮原始结果数略有差异，属于搜索结果在不同时间的正常波动。验收关注的是每个关键词都拿到当轮真实页面并完成解析，不能要求三轮结果条数完全相同。

十五、怎样把这套方法迁移到其他批量查询

这套优化最值得复用的部分是处理顺序。先把真实成功定义清楚，再测清外部请求的失败分布；随后保留成功会话，给不同失败设置不同恢复时间；最后才调全局并发和单 IP 并发。若一开始只追求线程数，很容易把代理池更快地送进风控。

迁移时建议先跑一小批代表性关键词，至少记录响应体积、最终地址、验证码比例、解析成功率和每类错误耗时。确认解析器能识别当前页面后，再放大到全量。全量验收至少连续运行三轮，并逐轮核对关键词成功数、失败原因、原始结果量、任务耗时和数据库收尾耗时。