数据库分库分表

转自阿里技术公众号，地址：https://mp.weixin.qq.com/s/X6FI9Ci7ZXGDNDCkh2VnNA

先说一下我的个人感受，就是我感觉可以与redis进行类比。主从复制-读写分离可以类比于redis的主从复制-哨兵模式，然后分库分表可以类比于redis的集群模式。总得来说，我感觉对于大规模数据的优化，主从复制-读写分离算是初级的优化，然后如果数据规模进一步庞大和QPS变得更加巨大的话，就要使用分库分表了。

其实吧，我感觉分库其实就隐含了分表了吧。。。我感觉直接分库就已经能解决很多问题了。。。

一  什么是分库分表？

其实就是字面意思，很好理解：

• 分库：从单个数据库拆分成多个数据库的过程，将数据散落在多个数据库中。

• 分表：从单张表拆分成多张表的过程，将数据散落在多张表内。

2  为什么要分库分表？

关键字：提升性能、增加可用性。

从性能上看

随着单库中的数据量越来越大、数据库的查询QPS越来越高，相应的，对数据库的读写所需要的时间也越来越多。数据库的读写性能可能会成为业务发展的瓶颈。对应的，就需要做数据库性能方面的优化。本文中我们只讨论数据库层面的优化，不讨论缓存等应用层优化的手段。

如果数据库的查询QPS过高，就需要考虑拆库，通过分库来分担单个数据库的连接压力。比如，如果查询QPS为3500，假设单库可以支撑1000个连接数的话，那么就可以考虑拆分成4个库，来分散查询连接压力。

如果单表数据量过大，当数据量超过一定量级后，无论是对于数据查询还是数据更新，在经过索引优化等纯数据库层面的传统优化手段之后，还是可能存在性能问题。这是量变产生了质变，这时候就需要去换个思路来解决问题，比如：从数据生产源头、数据处理源头来解决问题，既然数据量很大，那我们就来个分而治之，化整为零。这就产生了分表，把数据按照一定的规则拆分成多张表，来解决单表环境下无法解决的存取性能问题。

从可用性上看

单个数据库如果发生意外，很可能会丢失所有数据。尤其是云时代，很多数据库都跑在虚拟机上，如果虚拟机/宿主机发生意外，则可能造成无法挽回的损失。因此，除了传统的Master-Slave、Master-Master等部署层面解决可靠性问题外，我们也可以考虑从数据拆分层面解决此问题。

此处我们以数据库宕机为例： 

• 单库部署情况下，如果数据库宕机，那么故障影响就是100%，而且恢复可能耗时很长。 

• 如果我们拆分成2个库，分别部署在不同的机器上，此时其中1个库宕机，那么故障影响就是50%，还有50%的数据可以继续服务。 

• 如果我们拆分成4个库，分别部署在不同的机器上，此时其中1个库宕机，那么故障影响就是25%，还有75%的数据可以继续服务，恢复耗时也会很短。

当然，我们也不能无限制的拆库，这也是牺牲存储资源来提升性能、可用性的方式，毕竟资源总是有限的。

二  如何分库分表

1  分库？分表？还是既分库又分表？

从第一部分了解到的信息来看，分库分表方案可以分为下面3种：

2  如何选择我们自己的切分方案？

如果需要分表，那么分多少张表合适？

由于所有的技术都是为业务服务的，那么，我们就先从数据方面回顾下业务背景。 

比如，我们这个业务系统是为了解决会员的咨询诉求，通过我们的XSpace客服平台系统来服务会员，目前主要以同步的离线工单数据作为我们的数据源来构建自己的数据。

假设，每一笔离线工单都会产生对应一笔会员的咨询问题（我们简称：问题单），如果：

• 在线渠道：每天产生3w笔聊天会话，假设，其中50%的会话会生成一笔离线工单，那么每天可生成 3w * 50% = 1.5w 笔工单；

• 热线渠道：每天产生2.5w通电话，假设，其中80%的电话都会产生一笔工单，那么每天可生成 2.5w * 80% = 2w 笔/天；

• 离线渠道：假设离线渠道每天直接生成3w笔。

合计共 1.5w + 2w + 3w = 6.5w 笔/天

考虑到以后可能要继续覆盖的新的业务场景，需要提前预留部分扩展空间，这里我们假设为每天产生8w笔问题单。

除问题单外，还有另外2张常用的业务表：用户操作日志表、用户提交的表单数据表。

其中，每笔问题单都会产生多条用户操作日志，根据历史统计数据来可以看到，平均每个问题单大约会产生8条操作日志，我们预留一部分空间，假设每个问题单平均产生约10条用户操作日志。

如果系统设计使用年限5年，那么问题单数据量大约为 5年 * 365天/年 * 8w/天 = 1.46亿，那么估算出的表数量如下：

• 问题单需要：1.46亿/500w = 29.2 张表，我们就按32张表来切分；

• 操作日志需要 ：32 * 10 = 320 张表，我们就按 32 * 16 = 512 张表来切分。

如果需要分库，那么分多少库合适？

分库的时候除了要考虑平时的业务峰值读写QPS外，还要考虑到诸如双11大促期间可能达到的峰值，需要提前做好预估。

根据我们的实际业务场景，问题单的数据查询来源主要来自于阿里客服小蜜首页。因此，可以根据历史QPS、RT等数据评估，假设我们只需要3500数据库连接数，如果单库可以承担最高1000个数据库连接，那么我们就可以拆分成4个库。

3  如何对数据进行切分？

根据行业惯例，通常按照 水平切分、垂直切分 两种方式进行切分，当然，有些复杂业务场景也可能选择两者结合的方式。

（1）水平切分

这是一种横向按业务维度切分的方式，比如常见的按会员维度切分，根据一定的规则把不同的会员相关的数据散落在不同的库表中。由于我们的业务场景决定都是从会员视角进行数据读写，所以，我们就选择按照水平方式进行数据库切分。

（2）垂直切分

垂直切分可以简单理解为，把一张表的不同字段拆分到不同的表中。

比如：假设有个小型电商业务，把一个订单相关的商品信息、买卖家信息、支付信息都放在一张大表里。可以考虑通过垂直切分的方式，把商品信息、买家信息、卖家信息、支付信息都单独拆分成独立的表，并通过订单号跟订单基本信息关联起来。

也有一种情况，如果一张表有10个字段，其中只有3个字段需要频繁修改，那么就可以考虑把这3个字段拆分到子表。避免在修改这3个数据时，影响到其余7个字段的查询行锁定。(我感觉这是只进行分表，而不进行分库的最适合的情况了)

三  分库分表之后带来的新问题

1  分库分表后，如何让数据均匀散落在各个分库分表内？

比如，当热点事件出现后，怎么避免热点数据集中存取到某个特定库/表，造成各分库分表读写压力不均的问题。

其实，细思之下可以发现这个问题其实跟负载均衡的问题很相似，所以，我们可以去借鉴下负载均衡的解法来解决。我们常见的负责均衡算法如下：

2  分库分表环境下，如何解决分库后主键ID的唯一性问题？

在单库环境下，我们的问题单主表的ID采用的MySQL自增的方式。但是，分库之后如果还继续使用数据库自增的方式，就很容易出现各门口的主键ID重复问题。

对于这种情况，有很多种解决方案，比如采用UUID的方式，不过UUID太长，查询性能太差，占用空间也大，而且主键的类型也变了，也不利于应用平滑迁移。

其实，我们也可以对ID继续拆分，比如对ID进行分段，不同的库表使用不同的ID段，但也会产生新的问题，这个ID段要多长才合适？如果ID段分配完了，那可能会占用第二个库的ID段，产生ID不唯一问题。

但是，如果我们让所有的分库使用的ID段按照等差数列进行分隔，每次ID段用完之后，再按照固定的步长比递增的话，那是不是就可以解决这个问题了。

3  分库分表环境下，事务问题怎么解决？

由于分布式环境下，一个事务可能跨多个分库，所以，处理起来相对复杂。目前常见的有2种解决方案：

（1）使用分布式事务

• 优点：由应用服务器/数据库去管理事务，实现简单。

• 缺点：性能代价较高，尤其是涉及到分库数量较多时尤为明显。而且，还依赖于一些特定的应用服务器/数据库提供的分布式事务实现方案。

（2）由应用程序+数据库共同控制

• 原理：大事化小，将多个大事务拆分成可由单个分库处理的小事务，由应用程序去控制这些小事务。

• 优点：性能良好，少了一个分布式事务协调处理层。

• 缺点：需要从应用程序自身上做事务控制的灵活设计。从业务应用上做处理，应该改造成本高。

针对上面2种分布式事务解决方案，我们该如何选择？

首先，没有万能的解决方案，只有适合自己的方案。那就先看看我们的业务中，事务的使用场景有哪些吧。