由简入繁的高并发系统演进过程

参考：简书大佬文章

db压力：磁盘IO、网络IO、内存消耗、CPU负载

一、概述

        高并发系统各不相同，比如每秒百万并发的中间件系统、每日百亿请求的网关系统、瞬时每秒几十万请求的秒杀大促系统。他们在应对高并发的时候，因为系统各自自身特点的不同，所以应对架构都是不一样的。

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

        文章提供一个回答这类问题的思路，不涉及任何复杂架构设计。

二、最简单的系统架构

                                                                                         一个最简单的系统架构

三、系统集群化部署

        添加负载均衡层，将请求均匀打到系统层（系统层采用集群化部署多台机器，扛住初步的并发压力）

                  添加负载均衡层                    

四、数据库分库分表 + 读写分离

        随着用户量不断增加，系统负载也会随之增加。系统层面，你可以继续通过集群化的方式来扩容，反正前面的负载均衡层会均匀分散流量过去的。
        但是，这时数据库层面接受的请求量会达到3000/s，这个就有点问题了。因为db的读写并发过高，首先一个问题就是高峰期系统性能可能会降低，因为数据库负载过高对性能会有影响（每次到了高峰期，磁盘IO、网络IO、内存消耗、CPU负载的压力都会很高）。另外一个，压力过大有可能搞挂数据库。
        并发量继续增长时，我们就需要focus在数据库层面：分库分表（把一个库拆分为多个库，部署在多个数据库服务上，这时主库承载写入请求） + 读写分离（从库来处理读请求）

数据库层面

五、缓存集群引入  

        如果注册用户量越来越大，此时可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。
        但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。如果简单的不停的加机器，其实是不对的。所以在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。所以可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。

        具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。
        “数据库层面.jpg”里，读请求量目前是2000 qps/s，两个从库各自扛了1000 qps/s读请求，但是其中可能每秒1800次的读请求都是可以直接读缓存里的不怎么变化的数据的。此时一旦引入缓存集群，就可以抗下来这1800/s读请求，落到数据库层面的读请求就200/s。此时的架构图如下所示：

                                                                                              缓存集群

上述架构的好处是什么呢？ -> 降低机器成本
        未来，系统读请求达到每秒几万次了，但是可能80%~90%都是通过缓存集群来读的，而缓存集群里的机器可能单机每秒都可以支撑几万读请求，所以耗费机器资源很少，可能就两三台机器就够了。若换成是数据库，可能就要不停的加从库到10台、20台机器才能扛住每秒几万的读并发，成本是极高的。

小结：
(1) 不要盲目进行数据库扩容，数据库服务器成本昂贵，且本身就不是用来承载高并发的。
(2) 针对写少读多的请求，引入缓存集群，用缓存集群扛住大量的读请求。

六、引入消息中间件集群

        假如说所有写请求全部落地数据库的主库层，当然是没问题的，但是写压力要是越来越大了呢？比如每秒要写几万条数据，此时难道也是不停的给主库加机器吗？当然也可以，但是同理，耗费的机器资源是很大的，这个就是数据库系统的特点所决定的。
        相同的资源下，数据库系统太重太复杂，并发承载能力就在几千/s的量级。此时需要引入别的一些技术。比如说消息中间件技术，也就是MQ集群，他是非常好的做写请求异步化处理，实现"削峰填谷"的效果。
        假如说，现在每秒是1000/s次写请求，其中比如500次请求是必须请求过来立马写入数据库中的，但是另外500次写请求是可以允许异步化等待个几十秒，甚至几分钟后才落入数据库内的。此时可以引入消息中间件集群，把允许异步化的每秒500次请求写入MQ，然后基于MQ做一个削峰填谷。比如就以平稳的100/s的速度消费出来然后落入数据库中即可，此时就会大幅度降低数据库的写入压力。此时，架构图变成了下面这样：

                                                                                     消息中间件集群
        大家看上面的架构图，首先消息中间件系统本身也是为高并发而生，所以通常单机都是支撑几万甚至十万级的并发请求的。
        所以，他本身也跟缓存系统一样，可以用很少的资源支撑很高的并发请求，用他来支撑部分允许异步化的高并发写入是没问题的，比使用数据库直接支撑那部分高并发请求要减少很多的机器使用量。而且经过消息中间件的削峰填谷之后，减轻了数据库的压力。

七、总结：

        整体目标：让系统架构尽可能用最小的机器资源扛住外部更多的请求压力，减轻了数据库的负担。

1. 系统集群化
2. 数据库层面的 分库分表+读写分离
3. 针对读多写少的请求，引入缓存集群
4. 针对高写入的压力，引入消息中间件集群，实现"削峰填谷"的效果。