面试官:如何来设计动态扩容的分库分表方案?

面试官心理剖析:
这个问题主要是看看你们公司设计的分库分表设计方案怎么样的?你知不知道动态扩容的方案?

回答:

背景说明:如果你们公司之前已经做了分库分表,你们当时分了4个库,每个库4张表;公司业务发展的很好,现在的数据库已经开始吃力了,不能满足快速发展的业务量了,需要进行扩容。

1)停机扩容

这个方案跟单库迁移方案是一样的,就是停服进行数据迁移,不过现在的数据迁移比之前的单库迁移要复杂的多,还有数据量也是之前的好几倍,单库的数据量可能就几千万,但是现在是12个表,那么数据量是几十亿,可能光数据迁移就要花上好几个小时,等你的数据迁移完就已经上凌晨5点了,验证完可能都早上9点了,这样肯定是不行的,除非第二天你的系统还不能提供服务,那么用户来访问的时候,你们还在升级,这样你们公司就会损失很多钱。

2)双写扩容

这个方案也会变的很复杂,你的数据迁移工具也会写的很复杂。

3)动态扩容方案

比如你直接分32个库,每个库分32个表;
每个库的每秒写入并发是2000,单表的数据量为700万;
每秒写并发:32个库*2000=64000
数据量:1024个表*7000000=7168000000
如果你觉得你们公司的业务量发展会远远大于这个,那么可以直接扩容到更多的库。

刚开始的时候,你可以使用4个机器,每个机器上面建8个逻辑数据库;如果4个mysql不够用了,那么可以使用8个机器,创建4个数据库。
这个方案的好处就是,你不需要写数据迁移功能,只需要迁移数据库就可以了,然后代码这边只要修改配置就可以了。这个方案只是做整个数据库的迁移,没有数据的比较,没有临时工具,会方便很多。

如果你们公司不景气了,需要减少机器,那么也很方便,只要把该机器上的数据库迁移到其他机器上就好了,然后修改下我们的代码,改下路由配置就ok了。

路由规则:
库:userId 模 32(库数量);
表数据:(userId / 32) 模 32(表数量);

imagepng
如图,红色的表示扩容之后的。

本文为博主原创文章,未经博主允许不得转载。
更多内容请访问:IT源点

注意:本文归作者所有,未经作者允许,不得转载