面试官:如何来设计动态扩容的分库分表方案?
面试官心理剖析:
这个问题主要是看看你们公司设计的分库分表设计方案怎么样的?你知不知道动态扩容的方案?
回答:
背景说明:如果你们公司之前已经做了分库分表,你们当时分了 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(表数量);
如图,红色的表示扩容之后的。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于