后台服务器

凌晨三点，手机弹出一条告警：某台后台服务器 CPU 飙到 98%，服务持续了七分钟。后台我爬起来连上 VPN，服务打开终端，后台top 一眼扫过去——一个叫 logrotate 的服务进程把单核吃满了。原因不复杂：日志切分时撞上了正在写入的后台 12GB 访问日志，磁盘 I/O 卡死，服务CPU 等 I/O 等到发疯。后台这不是服务什么高深故障，但足以让整个后台服务响应时间从 80ms 跳到 2s。后台后台服务器就是服务这样，平时没人注意，后台一出事就是服务连锁反应。

很多人以为后台服务器就是后台“放在机房里的那台电脑”。差远了。它更像一个交通枢纽——所有请求先到这里，它决定谁先过、谁绕行、谁直接拒掉。你手机点个外卖，下单请求先到后台服务器，它要查库存、算配送费、写订单库、发消息队列，最后才返回“下单成功”。这中间任何一个环节慢了，用户端就是转圈圈。我见过最离谱的一次，某电商大促，后台服务器因为一个没加索引的 SELECT * FROM orders WHERE user_id = ?，把数据库连接池打满，整个下单链路瘫痪了 14 分钟。损失？按他们每秒订单量算，七位数。

后台服务器的核心矛盾从来不是“快”，而是“稳”。快很容易——堆硬件、加缓存、上 CDN。稳很难。你得考虑：数据库主从延迟了怎么办？Redis 突然连不上了怎么办？某个第三方 API 超时 30 秒，你的线程池会不会被拖死？这些破事不会同时发生，但总会在你最不想它发生的时候发生。我习惯在后台服务器上留一个 tcpdump 的抓包脚本，一旦网络抖动，先抓 30 秒包再说。别小看这个习惯，有一次就是靠抓包发现某台交换机端口间歇性丢包，运维查了一周没找到原因。

还有一点，后台服务器不是孤岛。它前面有负载均衡，后面有数据库、缓存、消息队列，旁边还有监控和日志系统。你改一行配置，可能影响整条链路。我见过一个运维把 nginx.conf 里的 worker_connections 从 1024 改成 65535，结果文件描述符没调，Nginx 直接起不来。后台服务器的脾气就是：牵一发而动全身。所以每次变更前，nginx -t 和 mysqld --validate-config 这种检查命令，我从来不敢省。

再说个反直觉的：后台服务器最怕的不是流量高峰，而是“慢查询”和“大事务”。流量高峰至少是可预测的——加机器、限流、降级，总有办法。但一个没加索引的 SQL，或者一个跑了 20 分钟还没提交的事务，能在毫无征兆的情况下把数据库拖垮。我现在的习惯是，任何新上线的接口，先跑一遍 EXPLAIN，看看有没有 type: ALL。有？打回去重写。后台服务器的性能问题，八成以上是数据库问题，而数据库问题里，八成以上是 SQL 写得太随意。

最后说句实在的：后台服务器没什么魔法。它就是一坨硬件、操作系统、中间件和业务代码的混合物。你尊重它的限制——内存有限、CPU 有限、磁盘 IOPS 有限——它就好好干活。你无视这些限制，硬塞、硬扛、硬重启，它迟早给你好看。凌晨三点的告警，从来不是无缘无故的。