给个例子，你的系统部署的机器是4核8G，数据库服务器是16核32G。

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

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

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

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

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

 

集群化部署

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

8核16gmysql能 8核16g服务器支持多少并发_高并发

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

对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这是作为主库承载写入请求的。

然后每个主库都挂载至少一个从库，由从库来承载读请求。

缓存集群引入

数据库其实本身不是用来承载高并发请求的

缓存系统的设计就是为了承载高并发而生，用缓存集群来承载大部分的读请求。

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

引入消息中间件集群

假如说你所有写请求全部都落地数据库的主库层，当然是没问题的，但是写压力要是越来越大了呢？

比如每秒要写几万条数据，此时难道也是不停的给主库加机器吗？

消息中间件技术，也就是MQ集群，他是非常好的做写请求异步化处理，实现削峰填谷的效果。