终于有大佬把分库分表的最佳实践讲清楚了

发布日期：2022/5/23 12:01:55      浏览量：

Part1 什么情况下需要考虑库表拆分呢？

实际上，是没有一个非常量化的指标来判定库表瓶颈的，因为每个系统的业务场景，查询复杂度都有不同。 但力有穷尽时，我们虽然可以尽量地从加从库读写分离、优化 sql、优化索引、复用连接等等方面进行优化，但总会有到达极限的时候的时候，量变引发质变。甚至，在真实生产环境，要更加未雨绸缪，不能等到崩了才去考虑。那么，应该怎么去判断已经到了库表拆分的时机呢：

• 硬件性能瓶颈，如果是读操作多，其实可以加多个从库分担主库读压力；但如果是写操作多，会因为主库磁盘 IO 增大，拖慢处理速度；另外，如果单表数据量过大，导致索引层级增多，扫描行增多，CPU 效率降低，影响 sql 执行效率，拖慢处理速度。而处理速度慢最终会导致连接数增加直至无连接可用。
• 日常运维投入，就如苏宁拼购的情况，如果一个月就要搞一次数据迁移，这个人力的投入产出比，应该是完全不匹配的，那就不如一次性搞定它。
• 业务发展可支持程度、难度和风险，当数据增长到一定程度，虽然没有达到极限，还能凑活，但是遇到活动型流量脉冲，无法完全支持业务需求；而业务需要进行迭代增加模式时，修改数据表带来的风险又比较大。就可以考虑重构数据模型，拆分库表了。

Part2 分库分表的目的和方案

2.1 业务数据解耦 - 垂直拆分

把不同的业务数据拆分到各自的数据库中独立维护，那么最底层的原因是什么呢？

是微服务下的上层服务拆分。为了满足快速迭代、安全发布、链路降级、主次业务解耦等问题，去解决代码大量冲突、小功能排队等待大版本发布等等问题，将业务按照一定逻辑进行拆解，形成一个个功能完备，独立运行的服务，然而，如果数据库层面不配合，就无法解决根本问题。当上层服务实例拆分后可以被大量横向扩展，以应对高并发的流量冲击，会导致底层数据库的承载压力和连接数急剧增加。

所以，通过垂直拆分将业务数据解耦，各管一事，以满足微服务的效能最大化。

2.2 解决容量和性能压力 - 水平拆分

对某一业务库，当数据增量达到了库瓶颈，或者表瓶颈，就要进行库表的水平拆分了。

我之前遇到的很多情况，总是先分表，解决单表的容量和读写性能问题，随着业务发展，单库也遇到瓶颈了再考虑分库。为啥不一步到位？

就像之前在阿里，新应用上来搞个百库百表？一来是因为一些用户规模和一些路由规则的问题；更重要的，不是所有公司其实不是所有的公司都和阿里一样有钱，有限的资源要用在更重要的生存问题上。如果你作为一个初创公司的架构，给出了一套可能撑 10 年的存储方案，感觉会被同事在心里怼，公司能活 3 年么就这么浪费？但肯定没有人说这话，因为我们还是希望所有公司都能蓬勃发展，蒸蒸日上的☺。

所以，拆分方法就很有讲究了，怎么分能让后续迭代发展的代价最小呢？

2.3 分多少合适？

表主要看容量，很多经验表明 上千万后性能会有显著下降，因此，我们可以把表容量定在一半多一点，600w。

库主要看的是连接数，我们以阿里对外售卖的云存储来大致估计，单库的连接数定在 4000 左右。抽象一个实际的评估案例来看：假如目前平台每天产生 10w 订单，峰值并发数 8000QPS，然后考虑业务扩展和增长的速率：

比如，业务是和银行合作扩展业务，将大小银行量级平均一下，估计每合作一家可以带来多大的增长量，这里假设是 5000 单 / 天 / 家，如果业务计划是每年度合作 10 家，那就是 5w，5 年以后每天的单量，理论上可能会到 25w / 天。加上现有的 10w, 峰值 35w。如果我们计划系统的容量需要支撑 3 年，或者说，3 年之后的该业务扩展会趋于平缓，那么我们可以大致的估计为：

表：（3 年 * 365 天 * 35w=3.8 亿 ）/600w = 63 约 64 张表 库：10000 并发 / 4000 = 2.5 , 可按 4 个库来处理

2.4 怎么分适合

• Hash 取模
• range 划分

Part3 拆分会带来的问题

• 分区键的选取
• • 分区键要足够的均匀，比如，用户表用 UID，订单表可以用 UID，也可以用订单 ID，商户表用商户 ID，问题表用会话 ID 等等，总之，一定可以找到业务上的唯一 ID。当然还有一些特殊的分区，比如，日表，月表，则要按时间来分，等等。
• 全局唯一主键 ID
• • 这个其实可以理解为分布式 ID 的生成问题
• 如何实现平滑数据迁移？
• • 好处是简单，风险小；缺点是业务有损。那就看这个损能不能接受了
• 事务问题
• • 之前由于数据都在一个库中，所以，只要保证一个本地事务就可以办到。现在数据被分到了多个库，那么事务如何保证，分布式事务的方式有很多：TCC、本地事务表 + 事务消息、最大努力通知，saga 等等。
• 查询问题
• • 之前一个库就能搞定的 join、count 等各种联合查询，将不复存在，老老实实在接口代码层面实现吧。

Part4 大厂案例，知识面扩展

4.1 大众点评分库分表的数据迁移

• 阶段一：数据双写，以老数据为准。通过对账补平差异
• 阶段二：导入历史数据，继续双写，读切到新数据。
• 阶段三：停掉双写，删除老数据完成迁移

4.2 淘宝万亿级交易订单的存储引擎

淘宝超级量级下的交易单是怎么解决存储性能等问题的：

以上就是本篇文章的索引内容，如有遗漏和错误，欢迎补充和指正。

作者：jacklin 链接：https://juejin.cn/post/7099322743522328583