三年架构设计：从0到10亿的数据库 scalability 实践

　　去年一月份那会儿，监控告警响得跟放鞭炮似的——凌晨三点半，主库的CPU直接飚到98%，慢查询堆得比机房的灭火器还高。我原以为又是哪个开发手滑写了全表扫描，结果一查，好家伙，新上线的推荐算法把历史订单表当缓存用了，三台机器的IO全卡在随机读上，连备份进程都被饿死了。

　　其实这事儿早有苗头。三年前刚接手的时候，系统才撑着百万级流量，开发说“分库分表太麻烦，先单表扛着”。我信了，结果第二年Q4大促，单表数据量冲到三千万，主从延迟直接蹦到十分钟——那天晚上我蹲在机房改配置，冷风从空调口灌进来，冻得手指头都打不了字，最后硬是把索引从B+树改成Hash，才勉强把延迟压到两分钟。可开发转头就跟我说：“下次还是得用单表，分库分表太影响开发效率。”

　　但这次不一样。十亿级的数据量，单表根本扛不住。我咬着牙把历史订单表拆成三十二个分片，每片配个独立从库，结果迁移当天，开发突然说“新算法要跨分片查询”。我盯着屏幕上的explain计划，血压直往上窜——跨分片JOIN？这帮人是不是觉得数据库是无限资源？最后没办法，只能把热点数据又捞出来做了个缓存层，结果缓存穿透又把Redis打挂了，半夜爬起来扩容的时候，泡面都凉透了。

　　其实最让我火大的是“优胜劣汰”这四个字。三年里，我试过无数种方案：从垂直分库到水平分表，从读写分离到多活架构，每次优化都像在走钢丝——改个索引可能引发锁表，扩个节点可能触发脑裂，连备份策略都得跟着业务特点调。有次为了压延迟，我把binlog格式从ROW改成STATEMENT，结果第二天开发找上门来说“数据不一致”，我查了半天才发现是触发器的问题——那玩意儿我早就忘了系统里还有这破东西。

　　跟开发吵过最凶的一次，是在分库分表方案上。他们坚持要用用户ID哈希分片，说这样查询简单；我非要按时间范围分，说这样归档方便。最后各退一步，用了用户ID+时间的复合分片键，结果上线后发现，按用户ID查确实快了，但按时间范围查反而更慢——因为分片键里带了时间，索引根本用不上。那天晚上我盯着慢查询日志，屏幕上的光晃得眼睛生疼，最后只能给每个分片单独建了个时间索引，磁盘空间直接少了三分之一。

　　其实有些坑本来能避免。比如去年迁移的时候，我忘了检查新机房的网络带宽，结果主从同步卡了半小时，开发在群里疯狂@我：“数据怎么还没同步？”我一边回“在查了”，一边盯着iftop的流量曲线，心里直骂自己——明明前一天还看到机房的人在搬交换机，怎么就忘了问带宽？后来还是临时把同步线程数从八调到四，才勉强把延迟压下去，可这时候天都快亮了，窗外的鸟都开始叫了。

　　但有些事，真的没法提前预料。比如上个月，某个分片的从库突然宕机，重启后发现数据文件坏了。我原以为有备份就能恢复，结果一查备份日志——好家伙，最近一次成功备份是三天前，而且备份文件还存在已经挂掉的旧存储上。那天我蹲在机房，看着运维小哥把旧硬盘拆下来，用dd命令一点点抢救数据，心里直发虚——要是这盘彻底坏了，十年前的数据都得丢，客户能把我生吞了。

　　其实三年下来，我最深的感触是：数据库扩容没有银弹。分库分表能解决单表瓶颈，但会带来跨分片查询的麻烦；缓存能减轻数据库压力，但会引入一致性问题；多活架构能提升可用性，但会复杂化数据同步。每次优化都是权衡，每次扩容都是妥协——就像走迷宫，你以为找到了出口，结果转个弯又进了死胡同。

　　现在系统撑到十亿级，我反而更慌了。开发又在提新需求，说要在订单表上加个全文索引，我盯着表结构，心里直打鼓——这表已经三百多个字段了，再加索引，IO不得炸？可他们说“用户需要搜索订单备注”，我能怎么办？只能硬着头皮上，大不了今晚又得蹲机房改配置。

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!