如何设计一个高并发系统？

如果你确实有真才实学，在互联网公司里，干过高并发系统，那你拿Offer，基本如探囊取物一样简单。

但你要真干过高并发系统，面试官绝对不会问这个问题，否则他就不太明智了。

因为真正干过高并发的人一定知道，脱离了业务的系统架构，都是纸上谈兵。

真正在复杂业务场景、而且还高并发的时候，这个系统架构一定很难搞。

要理解高并发，就得从高并发的根源出发——为什么会有高并发？为什么高并发就很牛X？

因为刚开始，系统都是连接数据库的，但是数据库支撑到每秒并发两三千的时候，基本就快完了。

数据库如果瞬间承载每秒5000、8000、甚至上万的并发，一定会宕机，因为比如MySQL就压根儿扛不住这么高的并发量。

所以为什么高并发牛X？

因为现在网民越来越多，很多App、网站、系统承载的都是高并发请求，高峰期每秒并发量几千都很正常。就像每年的双十一，一年比一年的峰值高，每秒并发几十万，都是洒洒水。

那么，我们可以从以下几个方面，来进行考虑：

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

2、缓存。必须得用缓存。大部分的高并发场景，都是读多写少。你完全可以在数据库和缓存里都写一份，然后读的时候，大量走缓存就行了。

3、MQ。必须得用MQ。

可能你还是会出现高并发写的场景，比如说一个业务操作里，要频繁搞数据库几十次，增删改增删改，疯了。

那你咋办？用MQ吧，大量写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在MySQL承载范围之内。

4、分库分表。可能到了最后，数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库，拆分为多个库，多个库来抗更高的并发。

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

5、读写分离。多数时候，数据库可能也是读多写少，没必要所有请求，都集中在一个库上。

可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。

6、Elasticsearch，可以考虑用ES。ES是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器，来抗更高的并发。

如何解决单点故障？

一个网站，从基础的硬件层、到操作系统层、到数据库层、到应用程序层、再到网络层，都有可能产生单点故障。

如果要有效地消除单点故障，最重要的一点，是设计的时候，要尽量避免引入单点，随着架构的变化，定期审查系统潜在的单点，也是有必要的。

大体可以从以下几个方面，来消除单点故障：

增加硬盘，做镜像。让出错的概率降低。

网卡与网线的单点问题。系统里面最容易物理损坏的就是网线，网卡绑定（NIC bonding）是一个很简单、很通用的办法，建议你配置多个网卡。

SSH服务器和Telnet服务器共存。毕竟SSH和Telnet，都不是百分之百靠谱的事；

IDC机房的单点。由于中国特色的“南北互通”，所以选择IDC机房的时候，一定要有冗余。

靠谱的DNS解析。

原文：https://blog.csdn.net/csdnnews/article/details/86065474