本次宕机一共五小时！！！本文源自 从 CPU 100% 到 宕机惊魂：我是如何通过 Redis + WAF + Swap 拯救我的服务器的 - 菩提网络 - 网络技术分享的网站 如果需要转载还请附带网站链接！！！
背景：流量突增引发的性能危机
昨晚，我发现网站的 Google 蜘蛛抓取频率异常飙升，达到了每小时 2000 次左右。对于我这台配置仅为 2核 2G 的服务器来说，这本该是好事，但服务器的 CPU 和内存占用却随之报警，负载居高不下。为了不影响正常用户访问，我被迫开启了一场“服务器拯救行动”。
第一阶段：清洗流量，拒绝无效爬虫
首先排查网站日志，我发现除了 Google 等正规蜘蛛外，还有大量第三方垃圾爬虫（如 Semrush、Majestic 等）在消耗服务器资源，它们对收录和流量没有任何帮助。
措施：重写 robots.txt 文件，明确禁止这些垃圾爬虫的 User-Agent。
结果：虽然规则已部署，但由于搜索引擎缓存机制，效果并非“立竿见影”，CPU 占用率下降不明显。必须寻找更底层的优化方案。
第二阶段：性能核心——引入 Redis 缓存
既然拦截需要时间，那就必须提升服务器的处理能力。我发现苹果CMS系统支持 Redis，于是果断在 PHP 和 CMS 后台启用了 Redis 缓存机制。
措施：安装 Redis 扩展，开启 CMS 缓存。
效果：效果立竿见影！mysqld 的 CPU 占用率瞬间大幅下降，数据库不再是瓶颈。
第三阶段：WAF 防御——精准封杀恶意采集
解决了数据库压力，我发现日志中仍有大量高延迟请求。仔细分析 User-Agent 后发现一个有趣的现象：
我的正版 APP 使用的 UA 是 Dart/3.5 (Flutter开发)。
而大量导致卡顿的请求 UA 却是 okhttp/3.x。
很明显，这是有人在用脚本或盗版软件恶意采集我的接口。
措施：在 Cloudflare WAF 中配置规则，精准拦截包含 okhttp 的 User-Agent。
优化：同时在 robots.txt 中屏蔽了 /api.php 和 /search/ 等高消耗路径，防止蜘蛛抓取无意义的搜索结果页，这不仅节省了算力，还有助于提升网站权重的“抓取预算” (Crawl Budget)。
第四阶段：宕机惊魂与系统兜底
本以为一套组合拳下来可以高枕无忧，结果今天早上醒来，发现网站 “拒绝连接” (Connection Refused) ，SSH 连上去发现宝塔面板都挂了。
重启宝塔后分析，发现 Redis 和 MySQL 进程全都意外停止。结合日志分析，真相大白：凌晨的高负载任务（可能是备份或采集）导致内存瞬间耗尽，触发了 Linux 的 OOM Killer（内存溢出杀手），系统为了自保杀掉了数据库进程。
为了防止悲剧重演，我进行了最后的兜底配置：
限制 Redis 胃口：在配置文件中将 maxmemory 限制为 256MB，防止它无限制占用内存。
增加系统缓冲：利用 Linux 工具箱，添加了 2048MB 的 Swap (虚拟内存)。
总结
经过这一波三折的优化，目前服务器各项指标已完全恢复正常：
流量清洗：Cloudflare 挡住了恶意采集。
性能加速：Redis 缓存了 90% 的热点请求。
系统维稳：Swap 和内存限制确保了服务器不会再因 OOM 而宕机。
做运维果然是“走一步看一步”，但每一次故障都是一次成长的机会。现在的服务器，即使面对更高并发，也能稳如泰山了。
但是还有一些需要关注的点
关注磁盘空间：
“由于我的图片策略是‘本地保存’，随着采集量的增加，磁盘空间可能会成为下一个瓶颈。后续计划定期清理无用图片，或者在磁盘占用达到 80% 时迁移至对象存储。”
监控 Google Search Console：
“虽然暂时屏蔽了搜索页的收录，但为了确保正片被正常抓取，我已经向 Google 提交了最新的 Sitemap 地图，预计未来一周内收录质量会有质的飞跃。”
关于 Swap 的说明：
“虽然 Swap 会导致速度变慢，但在小内存 VPS 上，‘慢一点’总比‘直接挂掉’要好得多。这是小成本运营的必经之路。”
