并发量预估法
假设系统用户量总共就10万，用户量很少，日活用户按照不同系统的场景有区别，我们取一个较为客观的比例，10%吧，每天活跃的用户就1万。
按照28法则，每天高峰期算他4个小时，高峰期活跃的用户占比达到80%，就是8000人活跃在4小时内。
然后每个用户对系统发起的请求，我们算他每天是20次吧。那么高峰期8000人发起的请求也才16万次，平均到4小时内的每秒（14400秒），每秒也就10次请求。
单体系统架构
这个架构大家都不陌生不做过多阐述了。
系统集群架构
如果系统内处理的是较为复杂的一些业务逻辑，是那种重业务逻辑的系统的话，是比较耗费CPU的。4核8G的机器每秒请求达到500/s的时候，很可能你会发现你的机器CPU负载较高了。然后数据库层面，以上述的配置而言，其实基本上1500/s的高峰请求压力的话，还算可以接受。可以在应用服务器前面挂一个负载均衡层，把请求均匀打到系统层面，让系统可以用多台机器集群化支撑更高的并发压力。
-
添加负载均衡层，将请求均匀打到系统层。
-
系统层采用集群化部署多台机器，扛住初步的并发压力。
分库分表读写分离架构
随着业务量增长，数据库请求量也会不断增加，如果数据库接受的请求量达到3000/s以上，数据库可能会出现性能瓶颈了。每次到了高峰期，磁盘IO、网络IO、内存消耗、CPU负载的压力都会很高。压力过大数据库搞挂了怎么办。
这时可以引入分库分表 + 读写分离，把一个库拆分为多个库，部署在多个数据库服务上，主库承载写入请求的，每个主库都挂载至少一个从库，由从库来承载读请求。
引入缓存集群
根据系统的业务特性，如果写少读多的请求的场景，引入缓存集群减小数据库压力。
写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。
-
数据库服务器成本昂贵，不要盲目数据库扩容，且本身就不是用来承载高并发的
-
针对写少读多的请求，引入缓存集群，用缓存集群抗住大量的读请求
引入消息中间件
当写压力要是越来越大，不停的添加主库，消耗机器资源很大。对一些不急于落库的信息数据，可以引入消息中间件，将写请求异步化处理，实现削峰填谷的效果。
如现在1000/s次写请求，其中500次请求是必须请求过来立马写入数据库中的，但是另外500次写请求是可以允许异步化等待个几十秒，甚至几分钟后才落入数据库内的。
那么此时可以引入消息中间件集群，把允许异步化的每秒500次请求写入MQ，然后基于MQ做一个削峰填谷。比如就以平稳的200/s的速度消费出来然后落入数据库中即可，此时就会大幅度降低数据库的写入压力。
让系统架构尽可能用最小的机器资源抗住了最大的请求压力。
