互动直播开发高并发的数据库分库分表方案
做互动直播开发的同学都知道，真正让人睡不着觉的不是代码写不出来，而是系统在大流量冲击下突然挂了。特别是像我们声网这样做全球实时互动云的，平台上面跑着几十万个并发连接那是家常便饭。数据库作为整个系统的数据基石，一旦扛不住压力，前面做的再多优化都等于零。今天就聊聊我们在高并发直播场景下是怎么做数据库分库分表的，把踩过的坑和积累的经验分享出来。
先搞明白直播场景的数据库压力到底特殊在哪
在进入分库分表的具体方案之前，我们必须先理解互动直播这个场景对数据库来说到底意味着什么。不同于普通的电商或者社交应用，直播的数据访问模式有着非常鲜明的特点，这些特点直接决定了我们的架构设计方向。
首先看时间维度上的压力分布。直播流量呈现极强的波峰波谷效应，一场热门直播可能在几分钟内涌入几十万观众，这几十万人在几秒钟内同时产生大量的点赞、评论、礼物打赏等互动行为。也就是说，数据库要在极短的时间内承受正常状态下几十倍甚至上百倍的写入压力。这不是均匀分布在一天中的压力，而是集中在某些时间节点上的脉冲式冲击。很多同学在设计之初低估了这种脉冲效应的威力，结果就是数据库在流量高峰期频频告警。
然后是数据访问的热度分布极不均匀。在一场直播中，热门主播的直播间数据访问量可能占到整个平台总访问量的百分之三四十，而大量小主播的直播间访问量加起来可能也就百分之十。热点数据的集中效应意味着我们不能简单地做平均主义式的分片，必须要有机制来应对热点数据的处理。而且这些热点数据是动态变化的，今天的热门主播可能明天就过气了，分片策略需要具备动态调整的能力。
再一个就是数据的时效性要求非常高。直播互动的一大特点就是实时性，用户发的评论希望立刻被看到，送的礼物希望立刻有效果反馈。这意味着我们对数据库的延迟要求是毫秒级的，不能像处理日志那样攒批写入。同时，很多数据又有短期有效期的特性，比如用户进入直播间的状态、礼物特效的播放记录等，这些数据的生命周期很短，但访问频率极高。
分库分表的核心策略选择
搞清楚了场景特点，接下来就是具体的分库分表策略选择了。这里我要多说一句，市面上关于分库分表的文章很多，但很多都是泛泛而谈，真正结合业务场景来讨论的不多。我们声网在实践中摸索出来的一套方法论，核心思路是根据数据特性进行分类处理，而不是一刀切。
水平切分与垂直切分的混合运用
水平切分和垂直切分是分库分表的两种基本思路。水平切分是把一张表的数据按行分散到多个库多张表中，比如按用户ID取模或者按时间范围分表。垂直切分则是把一张表按列拆成多张表，比如把用户基本信息和用户扩展信息分开存储。
在直播场景下，我们采用的是一个混合策略。以用户数据为例，用户的静态属性比如注册信息、实名认证状态这些变更频率很低的数据做垂直拆分，单独存到一张表里；而用户的动态数据比如最近的观看记录、互动行为这些高频访问的数据则做水平拆分，按照用户ID进行分片。这样做的好处是高频访问的数据被分散到多个库表中，不会因为某张表过大而成为瓶颈；而低频变更的静态数据则可以通过缓存来扛流量，减少数据库压力。
分片键的选择是成败的关键
分片键的选择直接决定了数据分布的均匀性和查询效率。在直播场景下，我们尝试过多种分片键方案，最终确定了一个多级分片键的策略。
对于核心的互动数据比如评论、点赞、礼物记录，我们采用复合分片键，主分片键是直播间ID，辅助分片键是时间维度。为什么要这么做？因为几乎所有的查询都是围绕直播间来的，用户进入一个直播间首先要获取这个直播间的互动历史。如果按用户ID分片，那查询一个直播间的所有评论就要跨很多分片，延迟会非常高。而按直播间ID分片，同一个直播间的所有数据都在一个分片上，查询效率极高。
加上时间维度的辅助分片键是因为同一个直播间的数据量也会随时间增长而变得很大，必须按时间再做拆分。我们一般按月份分表，每个月一张表，这样单表数据量可控，过期数据的归档和清理也比较好处理。代价是跨时间的查询需要路由到多张表，但这类查询在直播场景下相对较少，属于可以接受的取舍。
对于用户相关的数据，分片键则用用户ID。这里有一个细节需要注意，用户ID的生成规则会直接影响数据分布的均匀性。如果用户ID是自增长的，那按ID取模会导致数据分布不均匀，前面几个分片的数据量会明显大于后面的。所以我们建议在设计用户ID生成规则时加入随机因子，确保ID的分布足够离散。
数据一致性与事务处理
分库分表之后，最让人头疼的问题就是跨库事务和数据一致性问题。在单机数据库时代，我们可以用本地事务来保证数据的一致性，但一旦数据分散到多个库，这条路就走不通了。
在直播场景中，有一个典型的跨库事务场景：用户送礼物。礼物数据存在礼物库，用户余额存在用户库，直播间的收益统计存在另一个库。这三个操作必须同时成功或者同时失败，否则就会出现数据不一致。但分布式事务的代价太高，会严重影响系统性能。
我们的解决方案是尽量避免强一致性需求，改用最终一致性。具体做法是引入异步补偿机制，主操作完成后通过消息队列触发后续的库存扣减和收益统计。如果某个环节失败了，会有重试机制来保证最终一致性。这么做的好处是主流程的执行时间大大缩短，用户送礼物的感觉就是秒到账，而后台的统计会在几百毫秒内完成同步。对于用户来说体验上基本没有差别，但对系统性能的提升是巨大的。
当然，有些场景是必须保证强一致的，比如用户充值和提现。对于这些场景，我们使用分布式事务框架，但会刻意控制这类操作的占比，把它们和对性能要求极高的核心互动流程隔离开来。
扩容与迁移的那些坑
数据库扩容是每个快速发展团队都会面临的问题。我们在声网的发展过程中经历过多次扩容，积累了一些实战经验。
扩容最理想的状态是平滑扩容，也就是不需要停机，数据迁移过程对业务透明。实现平滑扩容的关键是做好数据迁移的双写机制。双写就是在老库和新库同时写入数据，通过数据同步工具把老库的数据迁移到新库，等数据同步完成后再把读流量切换到新库，最后下线老库。
这个过程中有几个坑需要特别注意。第一是双写期间的数据一致性问题，如果程序在双写过程中崩溃，可能导致新库数据缺失，所以我们增加了对账机制，定期比对老库和新库的数据，发现差异及时修复。第二是流量切换的灰度问题，直接切换风险太高，我们采用的是流量百分比切换，先切百分之一的用户到新库，观察没问题再逐步放大。第三是历史数据的处理，老库中肯定会有一些长期不活跃的数据，这些数据要不要迁到新库？如果全量迁移会导致迁移时间太长，我们的做法是只迁移活跃数据，冷数据单独归档处理。
还有一点经验之谈，扩容的时机选择非常重要。不要等到数据库已经接近瓶颈了才扩容，那时候压力会非常大，处理问题的空间也很小。我们一般会在容量使用率达到百分之六十左右就开始规划扩容，预留足够的安全余量。
高可用与容灾设计
分库分表之后，单点故障的影响范围变小了，但如果分库分表的管理组件挂了，整个系统还是会瘫痪。所以高可用设计要覆盖到整个数据访问链路。
我们的高可用设计分了几层。第一层是数据库本身的主从复制和故障切换，这个是数据库自带的能力，重点是配置好复制延迟的监控和自动切换的阈值。第二层是分片路由层的高可用，我们部署了多个路由服务实例，通过负载均衡来做流量分发，单个路由实例挂了不会影响全局。第三层是缓存层的高可用，直播场景下我们重度依赖缓存来扛读流量，缓存集群采用哨兵模式，自动故障转移。
这里要特别强调监控的重要性。分库分表之后，问题的定位变得复杂了，一次查询可能要经过路由、缓存、数据库等多个环节，哪个环节出问题都会导致最终失败。我们的做法是全链路埋点，从用户发起请求到返回结果，每个环节的耗时和状态都记录下来，出现问题可以快速定位。另外就是各个分片的数据量和QPS要单独监控，及时发现倾斜问题。
实战经验总结
说了这么多理论，最后聊点实操中的经验之谈。分库分表这个事儿，没有完美的方案，只有适合当前业务阶段的方案。早期业务量小的时候，不要过度设计，单库单表跑着挺好。等业务量上来了，分库分表是水到渠成的事儿，强行提前做反而会增加系统复杂度，维护成本高得吓人。
还有就是不要迷信开源方案。开源的分库分表中间件很多，功能也很完善，但不一定适合你的场景。我们当时调研了一圈，最后决定自研路由层，原因就是我们的查询模式比较特殊，开源方案很难满足需求。自研的好处是完全贴合业务，代价是要投入人力来维护。这个取舍要看团队的情况，不能一概而论。
测试环节一定要重视。分库分表的测试比单机数据库麻烦得多，要覆盖正常查询、跨分片查询、分片路由失败、扩容切换等各种场景。特别是跨分片查询的性能测试，很多人会忽略，结果上线后发现某些查询慢得离谱悔之晚矣。
写在最后，数据库架构的演进是持续的过程，分库分表不是终点而是中间状态。随着业务发展，可能还要面对更多的问题，比如多机房部署、跨地域同步等等。保持架构的灵活性和可扩展性，给未来的演进留好空间，这才是真正考验架构师功力的地方。技术选型没有绝对的对错，只有适合不适合，关键是要想清楚业务的真实需求到底是什么。
