目前消息中心的量级还不是很大，大概每天200多W数据的样子，并发也就几十到两百,其实一两年内都不一定有并发的问题，按道理来说只要分表就可以了，但是凡是还是必须考虑长远点，目前还是需要考虑分一下库，那么分多少库呢？ 设计可以动态扩容缩容的分库分表方案其实就是对我们服务的发展做一定的评估,根据吞吐量来计算要求的数据库梳理(比如一个数据库服务器2000并发,我们预计达到1W就设计5个库),根据数据量大小计算表数据(比如一个表我们最多放500W数据,预计5000W数据就放10个表)
一.扩充数据库服务器法：
- 1、设定好几台数据库服务器，每台服务器上几个库，每个库多少个表，推荐是32库 * 32表，对于大部分公司来说，可能几年都够了,即使不够,我们也可以让DBA对历史数据进行归档存储,比如只保留2年内的数据,2年前的数据进行归档存储,这样就可以循环使用了;
- 2、路由的规则，orderId 模 32 = 库，orderId / 32 模 32 = 表
如图，假设我们申请了4台数据库服务器，每台上面部署了8个数据库，每个数据库对于每张表分了32张表
- 3、扩容的时候，申请增加更多的数据库服务器，装好mysql，
倍数扩容，4台数据库服务器，扩到8台数据库服务器，16台数据库服务器，原来的数据库服务器的数据库数量倍数递减（比如原来有4台服务器，每台服务器部署8个数据库，现在扩容一倍，有8台数据库服务器，那么每台数据库服务器就只用放原来的一半数据库，4个数据库即可） - 4、由
dba负责将原先数据库服务器的库整个迁移到新的数据库服务器上去(比如这里的db0~db3)，,不需要进行数据迁移或者表迁移啥的，dba有很多工具，库迁移，比较便捷
- 5、我们这边只需要修改一下数据库地址的配置，调整原来的库的服务器地址为迁移后的库所在数据库服务器的地址即可
- 6、重新发布系统，上线，
原先的路由规则变都不用变，直接可以基于2倍的数据库服务器的资源，继续进行线上系统的提供服务
总结：
如果我们想一开始设计成以后不需要改业务代码的表设计，那么我们需要对自己的数据量和吞吐量做一定的计算，然后对分的库数量和表数量做评估。
比如说假定一台数据库服务器可以承受2000写并发，一张表我们预计存500W数据，我们这个32个数据库，32张表，最多可以放32*500W约=40亿的数据，后面申请服务器资源的话也只是对并发数量进行扩容，而不是对表存储量扩容。
