支撑日活百万用户的高并发系统，应该如何设计其数据库架构？

V-xin：ruyuanhadeng获得600+页原创精品文章汇总PDF

目录：

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

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

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

分库分表啊！

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

---

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

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

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

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

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

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

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

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

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

---

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

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

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

然