站群系统高并发实战：几十个站点扛住流量洪峰的配置与调优记录
手头管着几十个站点，站群系统跑起来倒不难，真正让人头疼的是流量一上来就集体趴窝。前年双十一大促，主站群流量瞬间翻了八倍，服务器直接卡死，后台登不进去，订单页面白屏了将近四十分钟。那次事故之后，我把整套高并发站点方案推倒重来，前后折腾了大半年，现在单台4核8G的机器扛住日均三十万PV基本没什么压力。下面这些实操细节，都是真金白银换来的。
一、服务器底子怎么打：别在配置上抠那几百块
做站群的人，预算往往全砸在域名和内容上，服务器能省则省。我一开始也这毛病，结果就是天天救火。现在我们的标配是：Web节点用4核8G、SSD硬盘、5M带宽起步，数据库单独拆一台8核16G的机器，Redis缓存池另开一台2核4G的小机器。这三台机器的分工必须明确，混在一起跑，高峰期CPU抢资源能把你急死。
带宽这块有个坑得提一嘴。站群站点多是静态资源请求，图片、CSS、JS这些如果全走源站带宽，5M根本不够看。我们的做法是静态资源全部甩到CDN上，源站只处理动态请求，带宽压力立刻降下来七成。另外，Nginx的worker_connections参数记得调，默认512并发数，改成10240，再配合worker_processes auto，让Nginx自己吃满CPU核数，光这一项调整就能把并发处理能力拉高一个档次。
二、缓存分层：让请求在到达数据库之前就被拦住
高并发的核心思路就一句话——能不让数据库干的活，全拦在外面。我们这套站群系统高并发站点方案里，缓存分了三层。第一层是Nginx的fastcgi_cache，把页面级缓存直接放在Web节点上，命中率能到六成左右，这层拦住的是重复的整页请求。第二层是Redis，存的是数据库查询结果和会话数据，比如站点配置、栏目列表这些变动不频繁的数据，全走Redis读，数据库压力又少三成。第三层是Opcode缓存，PHP环境务必开OPcache，把编译后的脚本缓存住，省掉重复编译的开销。
有个细节值得说：Redis的过期时间别设太整齐。我们早期图省事，所有缓存统一设3600秒过期，结果每到整点前后，缓存集中失效，请求全压到数据库上，瞬间飙红。后来改成在基础时间上加减随机值，比如3000到4200秒之间随机，把失效时间打散，数据库曲线就平滑多了。这种小调整不起眼，但真管用。
三、数据库调优：慢查询是并发最大的敌人
站群系统有个特点，站点多、表结构相似，但数据量分散。每个站点独立库的话，连接数容易爆；共用一个库的话，单表数据量又太大。我们折中的办法是按业务分库，把用户数据、内容数据、日志数据拆到不同库实例上，每个实例的连接数控制在合理范围，单表数据量压到五百万行以内。
索引这块我吃过亏。早期有个站点文章表没建联合索引，一个列表页查询扫了八十万行，响应时间直接干到三秒多，并发一上来数据库连接池瞬间打满。后来把status、category_id、publish_time三个字段建了联合索引，查询时间降到十几毫秒。慢查询日志一定要开，long_query_time设成1秒，每天扫一遍，发现一个灭一个，别攒着。
四、动静分离与限流兜底：给自己留条后路
动静分离前面提过CDN，但还有一层——把站点拆成静态站和动态接口。资讯类页面直接生成静态HTML，用户访问的是纯静态文件，Nginx处理这种请求跟玩儿似的，并发上万都不虚。只有登录、评论、下单这些需要交互的操作才走动态接口，动态请求量能压到总请求量的百分之五以内。
限流是最后一道防线。我们在Nginx层用limit_req模块对单个IP做请求频率限制，比如每秒最多20个请求，超出的直接返回503并记录日志。应用层再用Redis做令牌桶，对核心接口做细粒度限流。这套机制上线后，有次被恶意爬虫盯上，单IP每秒发起上千次请求，限流规则一触发，源站稳如老狗，就日志里多了一堆拦截记录而已。
五、监控与压测：方案行不行，数据说了算
方案写完不算完，得上压测。我们用JMeter模拟500并发持续压十分钟，观察CPU、内存、响应时间、错误率四个指标。第一次压测就露馅了，Redis连接数在并发300左右就打满了，原因是连接池最大连接数设的50太小，调到200之后顺利跑到500并发，平均响应时间控制在200毫秒以内。
监控这块，Zabbix和Prometheus都行，关键指标必须盯住：Nginx的活跃连接数、Redis的命中率和内存使用率、MySQL的QPS和慢查询数。我们设了告警阈值，Redis内存使用超过80%就发通知，MySQL慢查询每分钟超过5条就报警，提前介入比事后救火强太多。
整套站群系统高并发站点方案跑下来，硬件成本比原来多花了不到两千块一个月，但稳定性提升带来的收益远不止这个数。做站群是个长期活，底子打扎实了，后面加站点、上流量才有底气。希望这些实操细节能帮到正在跟并发较劲的朋友，少走点我们走过的弯路。