支撑200并发_你的系统如何支撑高并发？

高并发系统各不相同。比如每秒百万并发的中间件系统、每日百亿请求的网关系统、瞬时每秒几十万请求的秒杀大促系统。

他们在应对高并发的时候，因为系统各自特点的不同，所以应对架构都是不一样的。

另外，比如电商平台中的订单系统、商品系统、库存系统，在高并发场景下的架构设计也是不同的，因为背后的业务场景什么的都不一样。

最简单的系统架构

假设刚刚开始你的系统就部署在一台机器上，背后就连接了一台数据库，数据库部署在一台服务器上。

我们甚至可以再现实点，给个例子，你的系统部署的机器是 4 核 8G，数据库服务器是 16 核 32G。

此时假设你的系统用户量总共就 10 万，用户量很少，日活用户按照不同系统的场景有区别，我们取一个较为客观的比例，10% 吧，每天活跃的用户就 1 万。

按照 28 法则，每天高峰期算它 4 个小时，高峰期活跃的用户占比达到 80%，就是 8000 人活跃在 4 小时内。

然后每个人对你的系统发起的请求，我们算他每天是 20 次吧。那么高峰期 8000 人发起的请求也才 16 万次，平均到 4 小时内的每秒(14400 秒)，每秒也就 10 次请求。

好吧！完全跟高并发搭不上边，对不对？

然后系统层面每秒是 10 次请求，对数据库的调用每次请求都会有好几次数据库操作的，比如做做 crud 之类的。

那么我们取一个一次请求对应 3 次数据库请求吧，那这样的话，数据库层每秒也就 30 次请求，对不对？

按照这台数据库服务器的配置，支撑是绝对没问题的。上述描述的系统，用一张图表示，就是下面这样：

系统集群化部署

假设此时你的用户数开始快速增长，比如注册用户量增长了 50 倍，上升到了 500 万。

此时日活用户是 50 万，高峰期对系统每秒请求是 500/s。然后对数据库的每秒请求数量是 1500/s，这个时候会怎么样呢？

按照上述的机器配置来说，如果你的系统内处理的是较为复杂的一些业务逻辑，是那种重业务逻辑的系统的话，是比较耗费 CPU 的。

此时，4 核 8G 的机器每秒请求达到 500/s