一、前言

通过前面的文章，已经把用于功能开发的 整体技术架构 基本搭建好了， 缓存和异步消息架构也确定好了，是不是整体技术架构就可以了呢？

很显然不是，仍然有很多缺失的部分，比如对于高并发和海量数据的处理， 这两个基本上也算是目前实际应用当中的标配了，因此在高层架构设计阶段， 同样要对这样通用的功能 进行架构和处理方案的设计。

先来看看高并发问题的处理思路。

一：认识高并发问题

所谓高并发指的是：在同时或极短时间内，有大量的请求到达服务端，每个请求都需要服务端耗费资源进行处理，并做出相应的反馈。

高并发问题的本质就是：资源的有限性，比如：带宽、CPU、内存、IO等。

就是因为资源有限，我们不可能同时去处理并满足这些大量的请求，从而带来一系列的问题，统称就是高并发的问题。

二：高并发解决思路

从服务端来解决高并发问题的话：

核心思想：分而治之——请求分流。

现在不是同时来了太多的请求吗？我一台服务器肯定处理不过来啊，那我就开始分流，先增加服务器数量，比如增加到10台，然后把请求通过一定的算法，分散到这10台服务器去处理。

这样一来，每台服务器处理的量就下来了，从这台服务器的角度看，没有什么高并发，也没有什么大量请求，都在可支持的范围内搞定。

三：基本的处理方式：

1：提高应用处理的性能

举个例子，假设某个业务功能，现在需要1秒才能处理一个请求，那对于一个Web服务器Tomcat来说，假定Tomcat设置了500个线程，这已经不少了，也就是1秒最多能完成500个请求处理。

如果这个时候，提高应用处理的性能，到0.1秒就能处理一个请求了，还是这个Tomcat，还是这个配置环境，差不多每秒能处理5000个请求了。

也就是应用处理的性能越高，同样部署环境的情况下，应用支撑高并发的能力越强。

关于应用优化的内容非常多，每层、每种技术都有很多优化的方案和思路，这个我们可以另文再聊。

比如：前端静态化、CDN、多级缓存、分库分表、SQL优化等，从表现层一直到数据层，可优化的地方特别多，这里都笼统的称之为提升应用处理性能，以应对系统的高并发。

2：集群处理

就跟前面举例一样，如果应用的性能已经很难提升了，还是存在并发问题，怎么办呢？

那就采用集群来处理，一台服务器搞不定，那就多来几台。

比如现在同时有1万的并发请求过来，一台服务器每秒能搞定500个请求，那很简单，增加服务器到20台，前面用Nginx等进行流量分发，是不是很容易就支撑到1万请求了。

如果现在加到10万的并发请求呢，这个时候，就可以采用多级集群进行分流。比如ELB先分发到Nginx，这个时候Nginx也不是一个，假设来10个，每个Nginx后面再带着20个Tomcat，先不考虑高可用什么的，就先体会分而治之处理高并发的思想。

这样一来，落到每个Nginx上的流量还是1万，后面跟20个Tomcat，每个Tomcat还是只需要负责每秒500个请求的处理。

当然这里没有去考虑更多配套的资源，比如数据库是否能支持等问题。

3：异步加集群处理

如果通过集群还是很难处理高并发的请求量，比如现在加到了100万并发，这种特别是在搞一些大促活动的时候，容易出现这么高的峰值并发量。

那该怎么办呢？可以考虑异步加集群的方式来处理。异步在这里起到削峰的作用，把请求处理延后。

当请求通过ELB过后，先导向多个Nginx，这些Nginx后面跟的不是具体的应用功能处理的服务，而是把接收到的请求，包装成为消息，扔到消息系统里面去，也就是做一个请求服务消息发送的集群。

一般来说，消息系统集群的承载力是比较好的，而且是持久化的，不用太担心性能问题。

然后再做一个从MQ里面获取消息，再分发后端集群来处理的，这么一个消息的消费者集群。在这里就可以自己控制速度，也可以控制是否要处理这个业务。

比如：活动只有前1000名成功，那么这里成功处理了1000个请求，剩下的消息就可以丢弃，然后返回结果了。

高并发的处理有很多具体的方案，但大体都是这三大思路的具体化，或者是派生的思路，要应对高并发，思路总结起来就是：

1：应用自己跑快点， 就是提升应用的性能

2：还不行，就多来几个， 就是采用集群的方式，共同分担高并发请求

3：还不行，那就延后处理，把处理时间拉长，单位时间内要处理的请求数量也就降下来了，是不是有点耍无赖

有关于高并发问题，我们就先聊到这里。

如果你觉得本系列文章还不错，能够给你一些启发和思考的话，请关注、点赞、收藏加转发，让更多的朋友加入到我们的行列，谢谢啦！

更多架构师之路干货文章，已在路上，稍后就到！