();
陈帆盯着屏幕上那条突兀的CPU峰值曲线，手指在键盘上停顿片刻。故障日志已经记录完毕，问题出在任务调度逻辑的一个边界判断上——当某只股票数据缺失时，程序会反复重试，最终陷入循环。他合上故障报告窗口，重新打开爬虫模块的源码。
显示器左侧是旧版单线程采集脚本，右侧空白文档正等待写下新的架构。他的目光扫过服务器监控面板：两台机器的CPU空闲率依然稳定在百分之十五以上，内存使用不到一半。算力有了，现在缺的是把它们真正用起来的方式。
他新建项目，命名为“MultiSource_Crawler”。第一步不是写抓取逻辑，而是搭建线程管理器。系统必须能同时处理多个网页请求，又不能让网络和数据库被瞬间冲垮。他设置了一个最多八线程的池子，每个线程独立负责一个财经网站的轮询任务，主线程则统一控制启动、暂停与异常恢复。
第一个接入的是“新浪财经”。页面结构他已经熟记于心，股票列表页每三十秒刷新一次，行情数据嵌在表格中，需要用正则匹配提取代码、名称、最新价和成交量。他将这部分封装成独立函数，测试运行三次，均成功捕获目标字段。
接着是“搜狐财经”。这个站点的HTML更杂乱，广告脚本多，关键数据被包裹在多层div里。他花四十分钟梳理出稳定的路径规则，并加入容错机制——如果某次解析失败，线程不会立即退出，而是记录网址并延后重试。
第三个目标是“网易财经”。它的反爬策略稍严，连续访问五次后会出现验证码提示。他在每个请求之间加入随机间隔，从五百毫秒到两秒不等，模拟人工浏览节奏。同时，所有线程共享一组用户代理标识，避免同一IP频繁暴露。
凌晨两点十七分，三套采集模块全部就位。他启动主控程序，八个线程依次激活。状态栏显示：“【运行中】新浪财经 - 线程1｜搜狐财经 - 线程3｜网易财经 - 线程2……”
第一波数据开始流入。缓冲表里迅速堆积起数百条记录。他打开数据库性能监视器，观察写入速度。起初一切正常，但二十分钟后，磁盘I/O曲线突然拉高，延迟从原来的三百毫秒逐步攀升至四秒以上。
“不对。”他低声说。
切换到数据库后台，发现大量INSERT语句正在排队等待锁释放。进一步排查事务日志，问题浮现：三个线程可能同时提交同一只股票的数据，导致主键冲突，系统自动回滚并重试，形成连锁堵塞。
他立即暂停所有线程，关闭爬虫进程。解决办法不能靠降低并发，那样等于放弃效率提升。他考虑了几种方案，最终决定在数据入库前加一层过滤——用内存中的哈希表暂存已接收的记录指纹，只有未重复的数据才允许进入数据库。
他快速编写去重模块，以“股票代码 时间戳”作为唯一键值，每次新数据到达先查表比对。为防止内存溢出，他还设定了缓存上限，超出部分按先进先出原则清理。
改完后重新部署。凌晨四点零九分，第二次启动。
这一次，数据库压力显著下降。I/O响应恢复到毫秒级，连接池稳定维持在十二个活跃会话左右。他调出统计面板，计算单位时间内的有效入库量。
“每小时一百七十六条。”他默念。
相比过去手动录入或单线程抓取的每小时十来条，已是质的飞跃。他没有停下，继续优化解析规则，压缩不必要的字段读取，减少网络传输体积。清晨五点三十八分，系统连续运行六小时无中断，累计采集十万三千六百八十二条行情快照，覆盖沪深两市所有上市公司四月份的完整日线数据。
林悦推门进来时，正看到主屏上滚动刷新的入库记录。
“这么多？”她站在陈帆身后，声音有些发紧，“这些数据……全都能用？”
“大部分可以。”他调出校验报告，“人工录入时期三个月才录了八千多条，误差率零点三；这批自动采集的十万条，有效率九十一以上。剩下的问题是早期OCR识别留下的脏数据，比如把‘ST长控’认成‘SＴ长空’，但这类错误有规律，能用清洗规则批量修正。”
林悦走近屏幕，看着那一排排不断跳动的数字。“以前你总说我们看得太少，像摸黑走路。可现在……”她顿了一下，像是在估算眼前的信息量，“这够分析一辈子了。”
陈帆摇头。“还不够。”他打开另一个代码窗口，开始写一个新的类，“我们现在拿的是快照，是静态的片段。真正的市场是流动的，价格每秒钟都在变。我要让系统学会看活的数据。”
林悦没再说话，只是静静看着他敲下第一行代码。
那是一个基于长轮询的接口框架原型，目标指向**公开测试平台提供的实时行情流。虽然目前权限未开，协议细节也不明，但他已经开始准备接收逻辑。
上午八点二十三分，第一轮多源采集完成闭环验证。系统在无人干预下，持续六小时稳定获取三大网站数据，经过去重、清洗、格式化后，完整写入SQL Server主库。数据库总记录数首次突破十万大关。
陈帆保存当前版本，提交到本地代码仓库。他起身走到服务器机柜前，检查设备运行状态。两台机器风扇运转平稳，机箱温度正常，网口指示灯有节奏地闪烁绿光。
林悦收拾好自己的笔记本，临走前把一份早餐便当放在桌角。“别忘了吃。”她说。
陈帆坐在座位上，眼睛仍盯着新写的接口代码。他尝试构造一个模拟请求包，向本地测试端口发送心跳信号。屏幕弹出响应结果：连接建立，等待数据推送。
他修改超时参数，将默认的三十秒延长至一百二十秒，防止因短暂断流触发频繁重连。然后设定心跳间隔为五十秒，略低于服务端可能的检测周期，确保连接始终在线。
又调试了十几分钟，基本通信模型跑通。他深吸一口气，准备加入断线重连机制。
就在他敲下“while True:”这一行时，数据库监控窗口突然跳出一条警告。
新增数据流速骤降，三条采集线程中有两条显示“超时”，另一条虽保持连接，但返回内容为空白HTML。
他迅速切换到爬虫管理界面，查看各线程日志。几乎在同一时间，三家公司网站都加强了访问限制——IP请求频率阈值被调低，部分页面开始返回重定向指令。
他眯起眼，手指在键盘边缘轻轻敲击。
这不是偶然。
一定是系统在短时间内发起的高频请求引起了对方服务器的注意。尽管加入了随机延迟，但总量太大，终究还是触到了警戒线。
他没有立刻调整策略，而是先记录下各个站点的响应变化模式。新浪开始要求携带特定Cookie头，搜狐增加了JavaScript挑战，网易则直接封禁了来源IP的后续请求。
“得换方式了。”他自语。
现有的轮询机制已经走到极限。要想继续稳定获取数据，要么更换出口IP，要么改变请求行为，甚至可能需要模拟浏览器环境。
他新建一个文档，标题写着：“Headless_Client_Proxy”。
然后在下面列出几个关键词：虚拟用户代理池、动态Cookie管理、DOM渲染支持、代理跳转链路。
窗外阳光渐强，照在显示器上泛起微光。他揉了揉眼角，重新投入编码。
代码逐行生成，一个更复杂的客户端模型正在成型。它不再依赖简单的请求，而是试图构建一个能自主应对网页防护机制的自动化访问单元。
键盘敲击声持续不断。
服务器指示灯依旧规律闪烁，数据库连接数缓慢回升。
一条新的采集线程重新上线，使用更换后的IP和伪装头信息，试探性地发出第一个请求。