Linux 内核 Git 仓库被爬虫榨干 CPU 简直太离谱了
这种“背景辐射”级别的爬虫攻击现在已经成了很多公开仓库的噩梦。对于 git.kernel.org 这种级别的基础设施，如果它都被榨得这么惨，那很多小规模的开源项目或者数据服务简直没法活。
我之所以关注这个点，是因为我平时用 Datasette 部署了很多可以被爬取的数据页面，之前一直觉得只要服务器配置够高，多几个爬虫没关系，但看到 Linux 内核这种量级的受害者，我意识到这已经不是简单的“资源消耗”问题，而是一个严重的效率损耗。
很多爬虫根本不遵守 robots.txt，或者即便遵守了，也会通过极其高频的请求把服务器的渲染压力顶上去。特别是现在的 AI 训练数据集抓取，很多爬虫为了追求覆盖率，会无差别地把每一个 commit、每一个 diff 页面全部刷一遍。
从技术角度分析，渲染 HTML commit 页面其实是非常吃资源的，因为它涉及到数据库查询、版本对比渲染以及大量的字符串拼接。如果一个合法用户看一个 commit 页面，服务器跑一次；但如果一个恶意爬虫在 5 个节点上并发抓取，这 14 个核心就成了纯粹的“资源浪费机器”。
在这种环境下，单纯靠增加服务器配置根本解决不了问题，因为爬虫的规模增长速度永远快于硬件升级。我觉得现在必须得在基础设施层面对这种“无节制爬取”做硬限制。
如果要优化，我觉得可以尝试以下几个方向：
一、 强制缓存静态化
对于已经提交的 commit 页面，由于内容永远不会改变，应该直接通过 CDN 或者 Nginx 的强缓存机制拦截，绝对不能让请求直接打到后端渲染引擎上。
二、 实施基于行为的动态限流
不能只靠 IP 封禁，因为现在的分布式爬虫 IP 极其分散。得建立一套请求模式识别机制，比如一个 IP 在短时间内请求了大量连续的 commit ID，直接判定为爬虫，然后通过 429 Too Many Requests 把他挡回去。
三、 提供轻量化的 API 替代 HTML 页面
既然爬虫想要数据，与其让他们去解析沉重的 HTML，不如强制引导他们走一个极简的 JSON API，这样可以把 CPU 渲染开销降低 1-2 个数量级。
说到底，现在的互联网环境变得很奇怪，我们一方面希望开源项目被更多人看到，但另一方面，这些所谓的“数据采集”行为正在反噬提供数据的源头。如果一个项目的维护者因为服务器带宽或 CPU 爆表而不得不关闭公开访问，那才是真正的损失。
