云时代架构读后感8--支撑百万连接的系统应该如何设计其高并发架构

原文地址：

http://mp.weixin.qq.com/s?__biz=MzAwNTQ4MTQ4NQ==&mid=2453562447&idx=1&sn=1d24352be7c4478a030766a6f54470ba&chksm=8cd1312dbba6b83b3d362986cd0a24bc14a3f792c3f1a5c8e68df690ccea501dddbb50dae4b3&mpshare=1&scene=23&srcid=#rd

如果你设计一个系统需要支撑百万用户连接，应该如何来设计其高并发请求处理架构？

硬件设备在跟一个系统通信时，首先会跟你的系统建立连接，然后会基于那个连接发送请求给你的系统。

接着系统会返回响应给那个系统，最后是大家一起把连接给断开，释放掉网络资源。

一般的情况下每次发送请求，都必须要建立一个连接，然后再断开一个连接，但这是完全没有必要的。

完全可以多次通过一个连接发送请求和返回响应，这就是所谓的长连接。

但是如果说每个设备都要跟系统长期维持一个连接，那么对于系统来说就需要搞一个线程，这个线程需要去维护一个设备的长连接，然后通过这个连接跟一个设备不停的通信，接收人家发送过来的请求，返回响应给人家。

这种模式的缺点是很显而易见的，没法支撑大量连接。

而对于大名鼎鼎的消息系统Kafka来说，他也是会面对同样的问题，因为他需要应对大量的客户端连接。

针对这个问题，它采用的架构策略是Reactor多路复用模型。简单来说，就是搞一个acceptor线程，基于底层操作系统的支持，实现连接请求监听。

如果有某个设备发送了建立连接的请求过来，那么那个线程就把这个建立好的连接交给processor线程。

每个processor线程会被分配N多个连接，一个线程就可以负责维持N多个连接，他同样会基于底层操作系统的支持监听N多连接的请求。

如果某个连接发送了请求过来，那么这个processor线程就会把请求放到一个请求队列里去。

接着后台有一个线程池，这个线程池里有工作线程，会从请求队列里获取请求，处理请求，接着将请求对应的响应放到每个processor线程对应的一个响应队列里去。

最后，processor线程会把自己的响应队列里的响应发送回给客户端。

其中最关键的一个因素，就是processor线程是一个人维持N个线程，基于底层操作系统的特殊机制的支持，一个人可以监听N个连接的请求。

这是极为关键的一个步骤，就仅此一个步骤就可以让一个线程支持多个连接了，不需要一个连接一个线程来支持。

而且那个processor线程仅仅是接收请求和发送响应，所有的请求都会入队列排队，交给后台线程池来处理。 

比如说按照100万连接来计算，如果有100台机器来处理，按照老的模式，每台机器需要维持1万个线程来处理1万个连接。

但是如果按照这种多路复用的模式，可能就比如10个processor + 40个线程的线程池，一共50个线程就可以上万连接。

在这种模式下，每台机器有限的线程数量可以抗住大量的连接。

因此实际上我们在设计这种支撑大量连接的系统的时候，完全可以参考这种架构，设计成多路复用的模式，用几十个线程处理成千上万个连接，最终实现百万连接的处理架构。

转载于:https://www.cnblogs.com/sakura--/p/11051682.html