体育站群数据库集群部署实战：从单机到多节点的架构演进

为什么体育站群的数据层非拆不可

做体育类站群的朋友大概都有体会，比赛日一到，访问曲线几乎是一条垂直的线往上蹿。十几组站点共用一套数据，前端页面还没崩，数据库先开始转圈。我们最早那套单机 MySQL 跑在 8 核 32G 的机器上，平时负载不到 10%，遇上焦点赛事，连接数直接顶到 max_connections 上限，慢查询日志刷得跟流水账一样。

真正逼我们动手的是去年一次欧冠淘汰赛。凌晨三点，主库 IOPS 打满，三个站点白屏了将近七分钟。七分钟对体育资讯站来说，等于把当天的搜索流量拱手让人。那之后我们决定把体育站群数据库集群部署提上日程，目标很明确：读写分离、故障能切、扩容别太折腾。

集群拓扑怎么选：主从复制仍是性价比之选

方案调研阶段看过不少路线。云厂商的托管数据库省心，但站群这种多站点多库的结构，托管实例按量计费下来成本不低；分布式 NewSQL 倒是扩展性好，可团队里没人有生产环境的运维经验，不敢拿线上业务练手。绕一圈还是回到 MySQL 主从复制，一套一主两从加一个仲裁节点，配合中间件做读写分离。

具体到体育站群数据库集群部署的拓扑，我们最终定的是「一主三从」：一台主库承接所有写操作，两台从库分担列表页、详情页的读请求，第三台从库专门留给后台统计和报表查询。这么拆的好处是，后台跑大查询的时候不会跟前台抢资源。主从之间用半同步复制，牺牲一点写入延迟，换 binlog 至少落到一台从库上，心里踏实。

这里插一句，半同步复制的超时参数别照抄网上的默认值。我们设的 50ms 在高峰期反而拖慢了写入，后来调到 200ms 才顺。这点我没做压测对比，纯靠线上观察，不一定普适。

读写分离中间件的落地细节

中间件我们选的 ProxySQL，原因是它对站群这种多 schema 的场景支持得比较自然。每个站点独立一个库，ProxySQL 里按 schema 配路由规则，写请求指向主库组，读请求按权重分给两台从库。配置本身不复杂，麻烦的是把历史遗留的硬编码连接串全部替换掉。

• 先改测试环境，用影子流量跑了一周，确认路由规则没把写请求误判到从库
• 再按站点分批切，每晚切两组，切完盯半小时监控再继续
• 最后一天集中处理定时任务脚本，这类脚本最容易绕过中间件直连主库

整个切换花了六个晚上。中途出过一次事故：某个站点的后台编辑功能把 SELECT ... FOR UPDATE 发到了从库，锁没加上，导致两篇文章的浏览量数据重复累加。问题不严重，但提醒我们中间件的规则要按 SQL 指纹细化，不能只看语句开头。

故障切换：自动化之前先把人工流程跑熟

体育站群数据库集群部署里最容易出事的环节就是切换。我们一开始上了 Orchestrator 做自动故障转移，测试环境跑得挺好，真到线上演练时发现，主库假死的情况下自动切换会触发脑裂——两台从库都觉得自己该升主。后来加了仲裁节点和 fencing 机制才稳住。

现在我们的策略是半自动：监控告警触发后，值班同学确认主库确实不可用，手动执行切换脚本，全程大概 90 秒。听起来不快，但比自动切换的错误率低得多。切换脚本里固化了几步检查：从库延迟是否小于 5 秒、复制线程状态是否正常、VIP 漂移是否到位。每一步都有回显，不通过就停。

演练频率是每月一次，在业务低峰期做。有回演练发现备用的那台从库磁盘只剩 12% 空间，差点在切换后写满。这种事不演练根本发现不了。

监控与容量：别等报警了才看图表

集群上线后，监控面板从原来的三块扩到十一块。核心盯几个指标：主从延迟（超过 3 秒就查原因）、连接池使用率（85% 预警）、慢查询数量（每分钟超过 20 条要介入）、磁盘增长趋势（按周算增量，提前两周扩容）。

容量规划上我们走了弯路。初期按站点数平均分配从库权重，结果两个流量大户把其中一台从库压得喘不过气，另一台闲得发慌。后来改成按实际 QPS 动态调权重，每周复盘一次。这个调整没法一劳永逸，赛事排期变了，权重就得跟着动。

眼下这套体育站群数据库集群部署已经跑了十一个月，经历过两次焦点赛事的大流量冲击，最长的一次主从延迟到过 8 秒，但没有出现站点不可用的情况。下一步打算把报表从库换成列式存储，后台统计的查询速度应该还能再提一截。这块还在选型，有进展再聊。