1.先考虑一个最简单的系统架构
假设刚刚开始你的系统就部署在一台机器上,背后就连接了一台数据库,数据库部署在一台服务器上。
我们甚至可以再现实点,给个例子,你的系统部署的机器是4核8G,数据库服务器是16核32G。
此时假设你的系统用户量总共就10万,用户量很少,日活用户按照不同系统的场景有区别,我们取一个较为客观的比例,10%吧,每天活跃的用户就1万。
按照28法则,每天高峰期算他4个小时,高峰期活跃的用户占比达到80%,就是8000人活跃在4小时内。
然后每个人对你的系统发起的请求,我们算他每天是20次吧。那么高峰期8000人发起的请求也才16万次,平均到4小时内的每秒(14400秒),每秒也就10次请求。
好吧!完全跟高并发搭不上边,对不对?
然后系统层面每秒是10次请求,对数据库的调用每次请求都会好几次数据库操作的,比如做做crud之类的。
那么我们取一个一次请求对应3次数据库请求吧,那这样的话,数据库层每秒也就30次请求,对不对?
按照这台数据库服务器的配置,支撑是绝对没问题的。
上述描述的系统,用一张图表示,就是下面这样:
2.系统集群化部署
假设此时你的用户数开始快速增长,比如注册用户量增长了50倍,上升到了500万。
此时日活用户是50万,高峰期对系统每秒请求是500/s。然后对数据库的每秒请求数量是1500/s,这个时候会怎么样呢?
按照上述的机器配置来说,如果你的系统内处理的是较为复杂的一些业务逻辑,是那种重业务逻辑的系统的话,是比较耗费CPU的。
此时,4核8G的机器每秒请求达到500/s的时候,很可能你会发现你的机器CPU负载较高了。
然后数据库层面,以上述的配置而言,其实基本上1500/s的高峰请求压力的话,还算可以接受。
这个主要是要观察数据库所在机器的磁盘负载、网络负载、CPU负载、内存负载,按照我们的线上经验而言,那个配置的数据库在1500/s请求压力下是没问题的。
所以此时你需要做的一个事情,首先就是要支持你的系统集群化部署。
你可以在前面挂一个负载均衡层,把请求均匀打