后端架构师揭秘：这家网游资讯站的高并发架构之道

　　凌晨三点二十，我盯着监控屏右下角那个绿色小点——它还在跳，可首页的 UV 曲线塌了，像被抽掉骨头的蛇。值班室空调嗡嗡响，但比不上机房里那台老戴尔R720风扇的哀鸣，转速早飙到最大，听声音像要起飞。我伸手摸了摸机柜侧板，烫手，不是温的，是真烫，指甲盖一碰就缩回来。

　　客服在群里甩截图：「玩家反馈点开《新纪元》专题页直接 502」。我敲了两行 curl -I，回车，卡住。再敲，还是卡。第三遍加了 -v，等了四十来分钟才吐出一句 Connection timed out。这时候老板发来消息：「架构师在吗？玩家说页面白屏，微信生态链崩了？」他没打问号，句号收尾，字跟人一样硬。我回了个「在」，其实刚把泡面桶踢到桌底——那桶红烧牛肉面还剩半口汤，面坨得能当水泥块用。

　　我原以为是 CDN 回源超时，毕竟上周刚压测过边缘节点，TTL 设的是 30 秒，主站动静分离也跑得顺。结果切到源站看 nginx access.log，发现根本没进到入口层：上游 WAF 日志全空，TCP 连接连 SYN 都没收到几个。再查防火墙 conntrack 表，条目数不到阈值的三分之一。这不对劲——流量去哪儿了？

　　切磁盘看 df -h，/var/log 爆了，98%。但奇怪的是 /var/log/nginx 不大，撑死 12G；真正占坑的是 /var/log/journal，147G。谁把 journalctl 的 MaxUse 拉到 200G 了？翻 git 记录，是我上个月写的 ansible-playbook —— 当时想着“留点余量”，顺手把 default.conf 里的 Limit=200M 改成 200G。我手抖没抖，我不知道。现在它躺在那里，像一颗安静的哑弹。

　　journal 本身不致命，但 systemd-journald 写满之后会触发 fallback 机制：自动把日志刷进 /var/log/messages。而 /var/log/messages 早被 logrotate 命中过三次，每次 rotate 出来三个压缩包，每个包名后缀带 .gz.1、.gz.2、.gz.3。可今天那个 .gz.3 被 rm -f 了两次，第一次是同事凌晨一点十七分手动删的，他说「看着碍眼」；第二次是 Ansible 执行 clean-old-logs.yml 时删的——脚本没加条件判断，只认文件名后缀，不管是不是正在写的 active file。结果 journal 向 messages 疯狂 dump，messages 自己却一直没轮转，最后撑爆 /var。

　　磁盘满，systemd 卡死，sshd 启不动，ssh 连不上。我抱着笔记本蹲在机柜前插 VGA 线，手心全是汗。屏幕亮起那一刻，login 提示符闪了一下，又黑。我重插一次电源——不是服务器的，是我笔记本的。窗外雨下得不大，但檐角滴水砸在消防箱上的节奏特别准，哒、哒、哒，像秒表倒计时。

　　这时候 DBA 老张冲进来，工装裤膝盖磨得发亮，手里捏着一张皱巴巴的纸，上面画了三条线：主库、从库、离线备份机。「主从延迟 47 分钟，从库 binlog_pos 卡在 20240513_18:22:07；备份机最后一次 rsync 是三天前，昨天 cron 失败没告警——因为监控脚本自己挂在了 /tmp 下，/tmp 被清空过，没人记得重装」。他话没说完，我手机震，是运维群@全体成员，产品经理说「用户在评论区骂我们抄竞品 UI」，底下九个回复都带着截图，没有一条提技术故障。

　　最骚的是 DNS。不是解析失败，是解析成功但返回了错误 IP——缓存污染了。不是我们的 DNSPod，是我们自己部署的 dnsmasq 在 /etc/dnsmasq.d/gaming.conf 里配了一行 server=/api.gamez.com/192.168.10.21，结果那天 10.21 的机器重装系统，IP 没回收，新装机自动拿了同一个地址，但服务没起来。dnsmasq 照样转发，照旧 cache，照旧 TTL 七十二小时。我们监控的是 upstream 的健康检查状态，不是 dnsmasq 自身 cache 行为。这个点，我自己挖的坑，没设防。

文章配图，仅供参考

　　回过神来翻 Slack 历史，发现两小时前 DevOps 小王传过一个钉钉截图：证书即将过期提醒。是 Let's Encrypt 的，本来该自动 renew，但 cron 依赖的 certbot 路径在升级 Python 时被 alias 覆盖了，alias 是他配的，alias python=python3.11，而 certbot 原生只认 python3.9。所以他改了 /usr/local/bin/certbot 脚本头，把 #!/usr/bin/env python 改成 #!/usr/bin/env python3.9。结果呢？系统更新完内核后重装 python3.9 包，软链接断了，certbot 拒绝启动，日志里写了一句「exec format error」——其实是 interpreter not found，但他没点开看。这个细节我现在想起来胃还抽一下。

　　优胜劣汰。这个词不是我们拍脑袋想的，是这次扛下来的三个模块逼出来的：CDN 缓存策略、前端静态资源强缓存逻辑、用户行为日志异步队列。它们没崩溃，没拖后腿，因为它们早就被业务倒逼着反复捶打过三年——哪次版本上线没被玩家刷穿？哪次活动没遭遇突增三倍 UV？哪次攻防演练没被红队当成跳板？反倒是那些写在 PPT 里「高可用」「容灾」字样的服务，一个比一个脆。比如那个自研的「智能限流中心」，挂了两天，没人发现，因为所有人只看 QPS 和错误率，没人看它的健康探针响应时间——探针本身就在它上面跑。

　　我忽然想起上回搬家，打包箱上写着「数据库配置文件——勿拆封」，结果搬家公司贴错了标签，送到隔壁创业公司去了。对方工程师打开箱子，以为是同行馈赠，照单全收，拿去做了灰度验证……这事没造成事故，但我想起这事的时候，正盯着监控屏右上角那个胶布贴的「CPU 温度报警线已失效」便签条。胶布边角卷起来了，露出下面一行铅笔字：「上次修风扇是2023年冬至」。

　　现在是凌晨五点零八分，问题表面压住了：journal 截断、日志路径重建、dnsmasq cache 清掉、证书手动续上。但我知道，下次还会漏一个——可能是某个角落里的 redis aof rewrite 参数，可能是 CI 流水线里一个没关的 debug 模式，也可能就是哪个实习生删掉了 .gitignore 里的一行「/tmp/.tmp」。优胜劣汰？对。可淘汰的从来不是代码，是人盯错的那三分钟，是懒得翻的第十一页文档，是以为「应该没问题」的那个念头。

　　明天先把告警阈值调了。不调 CPU，不调内存，就调磁盘——/var/log 下任何目录连续五分钟超过 90%，立刻推企微+电话+短信三连。其他事，等我吃完这桶泡面再说。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!