体育站群数据库分库实战：单库扛不住之后，我们这样拆成多库并行

运营体育站群的朋友应该都经历过这个阶段：站群刚过几十个站点时，一台数据库还能顶住，等站点数量继续往上加、赛事数据全天候往里灌、会员登录行为越来越频繁，慢查询日志就开始刷屏，主库CPU长时间停在70%以上。这篇内容围绕体育站群的数据库分库方案来讲，把拆分逻辑、路由设计以及落地过程中踩过的坑说透，给同样被数据库卡住脖子的站长一份能对照的参考。

## 体育站群场景下，单库为什么总是先顶不住 体育站群的业务特征和普通内容站群差别不小。赛事比分、赛程、球队资料这类数据更新频率高，采集端几乎全天不停在写；文章内容和专题页的读取量很大，而且集中在比赛日前后爆发；会员注册登录、收藏、评论又带来大量零散的小事务。三类负载全压在一个库上，写锁和读锁互相抢资源，索引优化只能缓解一阵，站点数再涨一轮又回到老样子。 站点数量到80个左右时我们做过一次压测，单库QPS峰值冲到4200就开始出现明显的连接排队，慢查询里七成来自赛事表的范围扫描。这个结果说明问题不在SQL写得差，而是数据量和并发形态已经超出了单实例的合理承载范围。 ## 分库的整体思路：按业务线切，而不是按站点切 很多站长的第一反应是按站点ID取模分库，简单直接。体育站群其实不太适合这么干，因为站点之间的数据共享程度高，同一场比赛的比分可能被十几个站点引用，按站点切会把公共数据复制多份，同步成本反而更高。 这套方案选择按业务线拆分，划成三个独立库： - **赛事库**：赛程、比分、球队、联赛资料，写入密集，字段结构相对固定 - **内容库**：文章、专题、图集、标签关系，读多写少，允许一定延迟 - **会员库**：账号、登录日志、收藏、评论，事务性强，数据敏感 每个库再按数据热度做二级拆分。赛事库以赛季为单位做冷热分离，当赛季数据留在主表，历史赛季归档到独立实例；内容库按内容ID区间分表，单表控制在500万行以内；会员库按用户ID哈希分片，初期4个分片足够支撑百万级账号。 ## 路由层怎么设计才不添乱 分库之后最怕的是应用层到处写死库名，改一次配置牵动几十个站点。我们在应用和数据库之间放了一层轻量路由，站点程序通过统一入口拿连接，路由层根据SQL特征判断走哪个库：带赛事表特征的走赛事库，内容相关走内容库，会员事务走会员库。 路由规则写在配置文件里，新增分片只改配置不动代码。这一步在后期扩容时省了大量返工，站点程序基本没感知。路由层本身做无状态部署，前置一台Nginx做负载，单点故障的风险控制住了。 ## 读写分离和连接池的实操参数 主从结构是标配，一主两从，从库承担列表页和详情页的读请求。体育站群比赛日读流量能到平时的3倍，从库延迟控制在1秒以内基本不影响用户体验，比分这类强实时数据单独走主库读。 连接池参数调过几轮，最终单站点进程池上限设成20，空闲连接回收时间60秒，最大等待时间3000毫秒。池子开太大反而在主库上堆出一堆空闲连接，占着资源不干活。 ## 数据一致性和迁移的几个细节 跨库事务是分库后绕不开的问题。会员库和内容库之间有收藏、评论关联，我们没用分布式事务，改成业务层补偿：先写主库，异步消息推进从库关联表，失败进重试队列，超过3次落异常表人工处理。这套机制上线半年，补偿成功率在99.7%左右。 迁移阶段用双写过渡，老库和新库并行跑两周，用比对脚本抽样校验，确认差异清零再切读流量。切换窗口选在凌晨低峰，单次切换控制在15分钟内完成。 ## 分库之后要盯住的几个指标 库拆开了不代表万事大吉。日常要盯的是各分片的数据倾斜度，会员库哈希分片如果某个片超过均值20%就得检查哈希键有没有热点；赛事库的归档任务要确认按时执行，历史数据堆积会把冷库也拖慢；路由层的慢日志单独采集，分库后问题定位链路变长，没有独立日志很难查。 这套体育站群数据库分库方案在我们自己的站群上跑了将近一年，站点规模翻了一倍，数据库层面没有再出现全局性的性能事故。分库不是一劳永逸的事，拆分粒度、分片数量都要跟着业务量走，隔半年复盘一次分片负载，该加的加、该合的合，比一次性设计到位更实际。