如何设计能够动态扩容缩容的分库分表方案？

　　

　　对于分库分表来讲，主要是面对如下问题：

• 选择一个数据库中间件，调研、学习、测试；
• 设计你的分库分表的一个方案，你要分红多少个库，每一个库分红多少个表，好比 3 个库，每一个库 4 个表；
• 基于选择好的数据库中间件，以及在测试环境创建好的分库分表的环境，而后测试一下可否正常进行分库分表的读写；
• 完成单库单表到分库分表的迁移，双写方案；
• 线上系统开始基于分库分表对外提供服务；
• 扩容了，扩容成 6 个库，每一个库须要 12 个表，你怎么来增长更多库和表呢？

　　是你必须面对的一个事儿，就是你已经弄好分库分表方案了，而后一堆库和表都建好了，基于分库分表中间件的代码开发啥的都好了，测试都 ok 了，数据能均匀分布到各个库和各个表里去，并且接着你还经过双写的方案咔嚓一下上了系统，已经直接基于分库分表方案在搞了。

　　那么如今问题来了，你如今这些库和表又支撑不住了，要继续扩容咋办？这个可能就是说你的每一个库的容量又快满了，或者是你的表数据量又太大了，也多是你每一个库的写并发过高了，你得继续扩容。

　　这都是玩儿分库分表线上必须经历的事儿。

　　停机扩容（不推荐）

　　这个方案就跟停机迁移同样，步骤几乎一致，惟一的一点就是那个导数的工具，是把现有库表的数据抽出来慢慢倒入到新的库和表里去。可是最好别这么玩儿，有点不太靠谱，由于既然分库分表就说明数据量实在是太大了，可能多达几亿条，甚至几十亿，你这么玩儿，可能会出问题。

　　从单库单表迁移到分库分表的时候，数据量并非很大，单表最大也就两三千万。那么你写个工具，多弄几台机器并行跑，1小时数据就导完了。这没有问题。

若是 3 个库 + 12 个表，跑了一段时间了，数据量都 1~2 亿了。光是导 2 亿数据，都要导个几个小时，6 点，刚刚导完数据，还要搞后续的修改配置，重启系统，测试验证，10 点才能够搞完。因此不能这么搞。

　　优化后的方案

　　一开始上来就是 32 个库，每一个库 32 个表，那么总共是 1024 张表。

　　我能够告诉各位同窗，这个分法，第一，基本上国内的互联网确定都是够用了，第二，不管是并发支撑仍是数据量支撑都没问题。

每一个库正常承载的写入并发量是 1000，那么 32 个库就能够承载32 * 1000 = 32000 的写并发，若是每一个库承载 1500 的写并发，32 * 1500 = 48000 的写并发，接近 5 万每秒的写入并发，前面再加一个MQ，削峰，每秒写入 MQ 8 万条数据，每秒消费 5 万条数据。

　　有些除非是国内排名很是靠前的这些公司，他们的最核心的系统的数据库，可能会出现几百台数据库的这么一个规模，128个库，256个库，512个库。

　　1024 张表，假设每一个表放 500 万数据，在 MySQL 里能够放 50 亿条数据。

　　每秒 5 万的写并发，总共 50 亿条数据，对于国内大部分的互联网公司来讲，其实通常来讲都够了。

　　谈分库分表的扩容，第一次分库分表，就一次性给他分个够，32 个库，1024 张表，可能对大部分的中小型互联网公司来讲，已经能够支撑好几年了。

　　一个实践是利用 32 * 32 来分库分表，即分为 32 个库，每一个库里一个表分为 32 张表。一共就是 1024 张表。根据某个 id 先根据 32 取模路由到库，再根据 32 取模路由到库里的表。

orderId	id % 32 (库)	id / 32 % 32 (表)
259	3	8
1189	5	5
352	0	11
4593	17	15

　　刚开始的时候，这个库可能就是逻辑库，建在一个数据库上的，就是一个mysql服务器可能建了 n 个库，好比 32 个库。后面若是要拆分，就是不断在库和 mysql 服务器之间作迁移就能够了。而后系统配合改一下配置便可。

　　好比说最多能够扩展到32个数据库服务器，每一个数据库服务器是一个库。若是仍是不够？最多能够扩展到 1024 个数据库服务器，每一个数据库服务器上面一个库一个表。由于最可能是1024个表。

　　这么搞，是不用本身写代码作数据迁移的，都交给 dba 来搞好了，可是 dba 确实是须要作一些库表迁移的工做，可是总比你本身写代码，而后抽数据导数据来的效率高得多吧。

　　哪怕是要减小库的数量，也很简单，其实说白了就是按倍数缩容就能够了，而后修改一下路由规则。

　　这里对步骤作一个总结：

1. 设定好几台数据库服务器，每台服务器上几个库，每一个库多少个表，推荐是 32库 * 32表，对于大部分公司来讲，可能几年都够了。
2. 路由的规则，orderId 模 32 = 库，orderId / 32 模 32 = 表
3. 扩容的时候，申请增长更多的数据库服务器，装好 mysql，呈倍数扩容，4 台服务器，扩到 8 台服务器，再到 16 台服务器。
4. 由 dba 负责将原先数据库服务器的库，迁移到新的数据库服务器上去，库迁移是有一些便捷的工具的。
5. 咱们这边就是修改一下配置，调整迁移的库所在数据库服务器的地址。
6. 从新发布系统，上线，原先的路由规则变都不用变，直接能够基于 n 倍的数据库服务器的资源，继续进行线上系统的提供服务。