处理高并发问题思路

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请求压力下是没问题的。

所以此时你需要做的一个事情，首先就是要支持你的系统集群化部署。

你可以在前面挂一个负载均衡层，把请求均匀打到系统层面，让系统可以用多台机器集群化支撑更高的并发压力。

比如说这里假设给系统增加部署一台机器，那么每台机器就只有250/s的请求了。

这样一来&