高并发架构演进

单体系统架构

这个架构大家都不陌生不做过多阐述了。

系统集群架构

如果系统内处理的是较为复杂的一些业务逻辑，是那种重业务逻辑的系统的话，是比较耗费CPU的。4核8G的机器每秒请求达到500/s的时候，很可能你会发现你的机器CPU负载较高了。然后数据库层面，以上述的配置而言，其实基本上1500/s的高峰请求压力的话，还算可以接受。可以在应用服务器前面挂一个负载均衡层，把请求均匀打到系统层面，让系统可以用多台机器集群化支撑更高的并发压力。

1. 添加负载均衡层，将请求均匀打到系统层。

2. 系统层采用集群化部署多台机器，扛住初步的并发压力。

 分库分表读写分离架构

随着业务量增长，数据库请求量也会不断增加，如果数据库接受的请求量达到3000/s以上，数据库可能会出现性能瓶颈了。每次到了高峰期，磁盘IO、网络IO、内存消耗、CPU负载的压力都会很高。压力过大数据库搞挂了怎么办。

这时可以引入分库分表 + 读写分离，把一个库拆分为多个库，部署在多个数据库服务上，主库承载写入请求的，每个主库都挂载至少一个从库，由从库来承载读请求。

引入缓存集群

根据系统的业务特性，如果写少读多的请求的场景，引入缓存集群减小数据库压力。

写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。

• 数据库服务器成本昂贵，不要盲目数据库扩容，且本身就不是用来承载高并发的

• 针对写少读多的请求，引入缓存集群，用缓存集群抗住大量的读请求

 引入消息中间件

当写压力要是越来越大，不停的添加主库，消耗机器资源很大。对一些不急于落库的信息数据，可以引入消息中间件，将写请求异步化处理，实现削峰填谷的效果。

如现在1000/s次写请求，其中500次请求是必须请求过来立马写入数据库中的，但是另外500次写请求是可以允许异步化等待个几十秒，甚至几分钟后才落入数据库内的。

那么此时可以引入消息中间件集群，把允许异步化的每秒500次请求写入MQ，然后基于MQ做一个削峰填谷。比如就以平稳的200/s的速度消费出来然后落入数据库中即可，此时就会大幅度降低数据库的写入压力。

 让系统架构尽可能用最小的机器资源抗住了最大的请求压力。

并发量预估法

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

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

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

中间件并发实践

数据库

通常选用机器配置最低在8核16G，正常应该在16核32G。

8核16G的Mysql，正常1000以上并发没问题。

16核32G的Mysql，正常2000-3000并发。

一般来说，对那种普通配置的线上数据库，建议读写并发加起来不要超过3000/s。

应用服务器

4核8G的机器每秒请求达到500/s的时候性能会降低。

消息中间件

中间件系统本身也是为高并发而生，所以通常单机都是支撑几万甚至十万级的并发请求的。

典型推荐

cpu 核数 32

内存 32GB

磁盘 3TB 7200转 SAS盘三块

带宽 1Gb/s

缓存

单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。

每个节点的读写高峰qps可能可以达到每秒 5 万，32G 内存+ 8 核 CPU + 1T 磁盘，但是分配给 redis 进程的是10g内存，一般线上生产环境，redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。

负载均衡

关注公众号，发送 ms 免费获取 海量JAVA大厂面试题。