高并发系统的架构设计 2020面试必看

高并发的意义

其实所谓的高并发，如果你要理解这个问题呢，其实就得从高并发的根源出发，为啥会有高并发？为啥高并发就很牛逼？

浅显一点，很简单，就是因为刚开始系统都是连接数据库的，但是要知道数据库支撑到每秒并发两三千的时候，基本就快完了。所以才有说，很多公司，刚开始干的时候，技术比较low，结果业务发展太快，有的时候系统扛不住压力就挂了。

当然会挂了，凭什么不挂？你数据库如果瞬间承载每秒5000,8000，甚至上万的并发，一定会宕机，因为比如mysql就压根儿扛不住这么高的并发量。

所以为啥高并发牛逼？就是因为现在用互联网的人越来越多，很多app、网站、系统承载的都是高并发请求，可能高峰期每秒并发量几千，很正常的。如果是什么双十一了之类的，每秒并发几万几十万都有可能。

那么如此之高的并发量，加上原本就如此之复杂的业务，咋玩儿？真正厉害的，一定是在复杂业务系统里玩儿过高并发架构的人

但是你没有，那么给你说一下该怎么回答这个问题

· 高并发系统的架构组成

系统拆分

将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，不也可以抗高并发么。

缓存

大部分高并发场景，都是读多写少，完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存.

毕竟Redis轻轻松松单机几万的并发,所以你可以考虑考虑你的项目里，那些承载主要请求的读场景，怎么用缓存来抗高并发

消息队列

可能你还是会出现高并发写的场景，比如一个业务操作里要频繁搞数据库几十次，增删改增删改疯了。那高并发绝对搞挂你的系统，你要是用Redis来承载写那肯定不行，人家是缓存，数据随时就被LRU了，数据格式还无比简单，没有事务支持

所以该用MySQL还得用MySQL。那你咋办？

用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在MySQL承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的

分库分表

可能到了最后数据库层面还是免不了抗高并发的要求

那么就将一个数据库拆分为多个库，多个库来抗更高的并发

然后将一个表拆分为多个表，每个表的数据量保持少一点，提高SQL跑的性能。

读写分离

大部分时候数据库可能也是读多写少，就没必要所有请求都集中在一个库，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库

Elasticsearch

ES是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来抗更高的并发。那么一些比较简单的查询、统计类的操作，可以考虑用ES承载，还有一些全文搜索类的操作，也可以考虑用ES