目录

• 用一个创业公司的发展作为背景引入
• 用多台服务器来分库支撑高并发读写
• 大量分表来保证海量数据下查询性能
• 读写分离来支撑按需扩容及性能提升
• 高并发下的数据库架构设计总结

这篇文章我们来聊一下对于一个支撑日活百万用户的高并系统他的数据库架构应该如何设计

看到这个题目很多人第一反应就是

分库分表啊

但是实际上数据库层面的分库分表到底是用来干什么的他的不同的作用如何应对不同的场景我觉得很多同学可能都没搞清楚。

---

一、用一个创业公司的发展作为背景引入

假如我们现在是一个小创业公司注册用户就20万每天活跃用户就1万每天单表数据量就1000然后高峰期每秒钟并发请求最多就10。

天哪就这种系统随便找一个有几年工作经验的高级工程师然后带几个年轻工程师随便干干都可以做出来。

因为这样的系统实际上主要就是在前期快速的进行业务功能的开发搞一个单块系统部署在一台服务器上然后连接一个数据库就可以了。

接着大家就是不停的在一个工程里填充进去各种业务代码尽快把公司的业务支撑起来如下图所示。

结果呢没想到我们运气这么好碰上个优秀的CEO带着我们走上了康庄大道

公司业务发展迅猛过了几个月注册用户数达到了2000万每天活跃用户数100万每天单表新增数据量达到50万条高峰期每秒请求量达到1万

同时公司还顺带着融资了两轮估值达到了惊人的几亿美金一只朝气蓬勃的幼年独角兽的节奏

好吧现在大家感觉压力已经有点大了为啥呢

---

因为每天单表新增50万条数据一个月就多1500万条数据一年下来单表会达到上亿条数据。

经过一段时间的运行现在咱们单表已经两三千万条数据了勉强还能支撑着。

但是眼见着系统访问数据库的性能怎么越来越差呢单表数据量越来越大拖垮了一些复杂查询SQL的性能啊

然后高峰期请求现在是每秒1万咱们的系统在线上部署了20台机器平均每台机器每秒支撑500请求这个还能抗住没啥大问题。

---

但是数据库层面呢

如果说此时你还是一台数据库服务器在支撑每秒上万的请求负责任的告诉你每次高峰期会出现下述问题

• 你的数据库服务器的磁盘IO、网络带宽、CPU负载、内存消耗都会达到非常高的情况数据库所在服务器的整体负载会非常重甚至都快不堪重负了

• 高峰期时本来你单表数据量就很大SQL性能就不太好这时加上你的数据库服务器负载太高导致性能下降就会发现你的SQL性能更差了

• 最明显的一个感觉就是你的系统在高峰期各个功能都运行的很慢用户体验很差点一个按钮可能要几十秒才出来结果

• 如果你运气不太好数据库服务器的配置不是特别的高的话弄不好你还会经历数据库宕机的情况因为负载太高对数据库压力太大了

---

二、多台服务器分库支撑高并发读写

首先我们先考虑第一个问题数据库每秒上万的并发请求应该如何来支撑呢

要搞清楚这个问题先得明白一般数据库部署在什么配置的服务器上。

通常来说假如你用普通配置的服务器来部署数据库那也起码是16核32G的机器配置。

这种非常普通的机器配置部署的数据库一般线上的经验是不要让其每秒请求支撑超过2000一般控制在2000左右。

控制在这个程度一般数据库负载相对合理不会带来太大的压力没有太大的宕机风险。

---

所以首先第一步就是在上万并发请求的场景下部署个5台服务器每台服务器上都部署一个数据库实例。

然后每个数据库实例里都创建一个一样的库比如说订单库。

此时在5台服务器上都有一个订单库名字可以类似为db_order_01db_order_02等等。

然后每个订单库里都有一个相同的表比如说订单库里有订单信息表那么此时5个订单库里都有一个订单信息表。

比如db_order_01库里就有一个tb_order_01表db_order_02库里就有一个tb_order_02表。

这就实现了一个基本的分库分表的思路原来的一台数据库服务器变成了5台数据库服务器原来的一个库变成了5个库原来的一张表变成了5个表。

然后你在写入数据的时候需要借助数据库中间件比如sharding-jdbc或者是mycat都可以。

---

你可以根据比如订单id来hash后按5取模比如每天订单表新增50万数据此时其中10万条数据会落入db_order_01库的tb_order_01表另外10万条数据会落入db_order_02库的tb_order_02表以此类推。

这样就可以把数据均匀分散在5台服务器上了查询的时候也可以通过订单id来hash取模去对应的服务器上的数据库里从对应的表里查询那条数据出来即可。

依据这个思路画出的图如下所示大家可以看看。

做这一步有什么好处呢

第一个好处原来比如订单表就一张表这个时候不就成了5张表了么那么每个表的数据就变成1/5了。

假设订单表一年有1亿条数据此时5张表里每张表一年就2000万数据了。

那么假设当前订单表里已经有2000万数据了此时做了上述拆分每个表里就只有400万数据了。

而且每天新增50万数据的话那么每个表才新增10万数据这样是不是初步缓解了单表数据量过大影响系统性能的问题

另外就是每秒1万请求到5台数据库上每台数据库就承载每秒2000的请求是不是一下子把每台数据库服务器的并发请求降低到了安全范围内

这样降低了数据库的高峰期负载同时还保证了高峰期的性能。

---

三、大量分表来保证海量数据下的查询性能

但是上述的数据库架构还有一个问题那就是单表数据量还是过大现在订单表才分为了5张表那么如果订单一年有1亿条每个表就有2000万条这也还是太大了。

所以还应该继续分表大量分表。

比如可以把订单表一共拆分为1024张表这样1亿数据量的话分散到每个表里也就才10万量级的数据量然后这上千张表分散在5台数据库里就可以了。

在写入数据的时候需要做两次路由先对订单id hash后对数据库的数量取模可以路由到一台数据库上然后再对那台数据库上的表数量取模就可以路由到数据库上的一个表里了。

通过这个步骤就可以让每个表里的数据量非常小每年1亿数据增长但是到每个表里才10万条数据增长这个系统运行10年每个表里可能才百万级的数据量。

这样可以一次性为系统未来的运行做好充足的准备看下面的图一起来感受一下

四、读写分离来支撑按需扩容以及性能提升

这个时候整体效果已经挺不错了大量分表的策略保证可能未来10年每个表的数据量都不会太大这可以保证单表内的SQL执行效率和性能。

然后多台数据库的拆分方式可以保证每台数据库服务器承载一部分的读写请求降低每台服务器的负载。

但是此时还有一个问题假如说每台数据库服务器承载每秒2000的请求然后其中400请求是写入1600请求是查询。

也就是说增删改的SQL才占到了20%的比例80%的请求是查询。

此时假如说随着用户量越来越大假如说又变成每台服务器承载4000请求了。

---

那么其中800请求是写入3200请求是查询如果说你按照目前的情况来扩容就需要增加一台数据库服务器.

但是此时可能就会涉及到表的迁移因为需要迁移一部分表到新的数据库服务器上去是不是很麻烦

其实完全没必要数据库一般都支持读写分离也就是做主从架构。

写入的时候写入主数据库服务器查询的时候读取从数据库服务器就可以让一个表的读写请求分开落地到不同的数据库上去执行。

这样的话假如写入主库的请求是每秒400查询从库的请求是每秒1600那么图大概如下所示。

写入主库的时候会自动同步数据到从库上去保证主库和从库数据一致。

然后查询的时候都是走从库去查询的这就通过数据库的主从架构实现了读写分离的效果了。

现在的好处就是假如说现在主库写请求增加到800这个无所谓不需要扩容。然后从库的读请求增加到了3200需要扩容了。

这时你直接给主库再挂载一个新的从库就可以了两个从库每个从库支撑1600的读请求不需要因为读请求增长来扩容主库。

实际上线上生产你会发现读请求的增长速度远远高于写请求所以读写分离之后大部分时候就是扩容从库支撑更高的读请求就可以了。

而且另外一点对同一个表如果你既写入数据涉及加锁还从该表查询数据可能会牵扯到锁冲突等问题无论是写性能还是读性能都会有影响。

所以一旦读写分离之后对主库的表就仅仅是写入没任何查询会影响他对从库的表就仅仅是查询。

---

五、高并发下的数据库架构设计总结

其实从大的一个简化的角度来说高并发的场景下数据库层面的架构肯定是需要经过精心的设计的。

尤其是涉及到分库来支撑高并发的请求大量分表保证每个表的数据量别太大读写分离实现主库和从库按需扩容以及性能保证。

这篇文章就是从一个大的角度来梳理了一下思路各位同学可以结合自己公司的业务和项目来考虑自己的系统如何做分库分表应该怎么做。

另外就是具体的分库分表落地的时候需要借助数据库中间件来实现分库分表和读写分离大家可以自己参考 sharding-jdbc 或者 mycat 的官网即可里面的文档都有详细的使用描述。