Linux + Nginx + PHP + MySQL：一台服务器撑起一个千万级访问的站

2018年我接手了一个日活五十万的图片社区。技术负责人离职前留的文档只有三行字：“Ubuntu 16.04，Nginx 1.10，PHP 7.0，MySQL 5.7，跑不动就加机器。” 结果双十一流量翻倍，四台2核4G的云服务器扛住了每小时两百万次请求。这套组合的极限远比你想象的高，前提是你得懂它怎么协作。

先拆开看。Linux负责管硬件——CPU怎么分、内存怎么给、磁盘读写排队顺序。Nginx是前台接待，PHP是后厨，MySQL是仓库。用户点开网页，Nginx立刻判断：这人是看静态图片还是查动态数据？静态的直接从磁盘拿，动态的才叫醒PHP。PHP把SQL语句递给MySQL，MySQL在内存和硬盘里翻找，返回结果，PHP拼成HTML，Nginx再递回浏览器。整个过程像流水线，任何一环卡住，整条线就堵。

我见过最蠢的配置是把PHP-FPM进程数开到200，以为并发高就该多开进程。结果内存吃光，Nginx开始报502。正确的做法是看free -m和vmstat，算出单进程内存占用，再反推进程数。比如每个PHP进程吃80MB，2G内存的机器留500MB给MySQL，剩下1.5G最多跑18个进程。多了反而触发swap，磁盘I/O飙升，响应时间从50ms涨到2秒。

MySQL的坑更隐蔽。默认的innodb_buffer_pool_size只有128M，你数据库有5G数据，它每次查都得读磁盘。改成2G后，查询速度直接快十倍。但别贪心——如果机器只有4G内存，给MySQL分3G，PHP一启动就OOM。Linux的OOM Killer会随机杀进程，有时候杀的是MySQL，有时候是PHP-FPM，毫无规律，排查起来像见鬼。

Nginx有个常被忽略的参数keepalive_timeout。默认65秒，意味着每个TCP连接空闲65秒才关闭。高并发下，连接数会堆积到内核上限，新用户进不来。调到10秒，配合worker_connections设成4096，单机能轻松扛住一万并发。我测过，一个纯静态文件服务，Nginx配好gzip和expires缓存，QPS能到三万。动态请求慢在PHP和MySQL，但Nginx可以同时挂PHP-FPM和静态文件服务，图片走独立location，不干扰动态链路。

这套组合最妙的地方在于它的可观测性。出问题时，top看CPU和内存，iostat看磁盘，tail -f /var/log/nginx/access.log看实时请求。有一次用户反馈页面时快时慢，我打开日志，发现某个IP每秒请求200次，全是同一个接口。查MySQL慢查询日志，发现那条SQL没走索引，全表扫描五百万行。加个索引，问题消失。整个过程没动一行代码，全是系统层面的调优。

很多人一上来就上Redis、上消息队列、上微服务，其实大部分项目用不着。Linux+Nginx+PHP+MySQL这套经典组合，维护成本低，资料多，出问题能搜到答案。我见过一个日活两万的电商站，就跑在一台1核1G的阿里云学生机上，照样稳定运行两年。老板省钱，技术员省心，用户没抱怨过慢。

当然它也有脾气。PHP-FPM的pm.max_requests默认是0，意味着进程永不重启。PHP代码里如果有内存泄漏，跑上一个月，内存占用能涨到初始值的三倍。设置成500，每个进程处理500个请求后自动重启，问题迎刃而解。MySQL的binlog默认开启，日志文件能撑爆磁盘。定期purge binary logs before now() - interval 3 day;，不然某天早上你会发现数据库突然只读。

这套技术栈像老式手动挡汽车，换挡时机得自己把握。但一旦摸透它的脾气，比任何自动挡都可靠。关键时刻你能一脚油门踩到底，不会因为电子系统误判而熄火。现在云厂商推容器、推Serverless，但底层还是Linux，Nginx还是那个Nginx，PHP和MySQL也没消失。学会这套组合，相当于掌握了服务器端的基本功，其他框架再花哨，底层逻辑都逃不开这几个环节。