【生产实践总结】支撑百万链接的系统应该如何设计其高并发架构？【石杉的架构笔记】

时间 2019-11-06

标签生产实践总结支撑百万链接系统应该如何设计并发架构石杉的架构笔记栏目系统架构繁體版

原文原文链接

欢迎关注我的公众号：石杉的架构笔记（ID:shishan100）程序员

周一至周五早8点半！精品技术文章准时送上！面试

精品学习资料获取通道，参见文末算法

（1）到底什么是链接？

假如说如今你有一个系统，他须要链接不少不少的硬件设备，这些硬件设备都要跟你的系统来通讯。

那么，怎么跟你的系统通讯呢？

首先，他必定会跟你的系统创建链接，而后会基于那个链接发送请求给你的系统。

接着你的系统会返回响应给那个系统，最后是你们一块儿把链接给断开，释放掉网络资源。

因此咱们来看一下下面的那个图，感觉一下这个所谓的链接究竟是个什么概念。

（2）为何每次发送请求都要创建链接？

可是你们看着上面的那个图，是否是感受有一个很大的问题。

什么问题呢？那就是为啥每次发送请求，都必需要创建一个链接，而后再断开一个链接？

要知道，网络链接的创建和链接涉及到屡次网络通讯，本质是一个比较耗费资源的过程。

因此说我们彻底不必每次发送请求都要创建一次链接，断开一次链接。

咱们彻底能够创建好一个链接，而后设备就不停的发送请求过来，系统就经过那个链接返回响应。

你们彻底能够屡次经过一个链接发送请求和返回响应，这就是所谓的长链接。

也就是说，若是你一个链接创建以后，而后发送请求，接着就断开，那这个链接维持的时间是很短的，这个就是所谓的短链接。

那若是一个设备跟你的系统创建好一个链接，而后接着就不停的经过这个链接发送请求接收响应，就能够避免不停的建立链接和断开链接的开销了。

你们看下面的图，体验一下这个过程。在图里面，两次链接之间，有不少次发送请求和接收响应的过程，这样就能够利用一个链接可是进行屡次通讯了。

（3）长链接模式下须要耗费大量线程资源

可是如今问题又来了，长链接的模式确实是不错的，可是若是说每一个设备都要跟系统长期维持一个链接，那么对于系统来讲就须要搞一个线程，这个线程须要去维护一个设备的长链接，而后经过这个链接跟一个设备不停的通讯，接收人家发送过来的请求，返回响应给人家。

你们看下面的图，每一个设备都要跟系统维持一个链接，那么对于每一个设备的链接，系统都会有一个独立的线程来维护这个链接。

由于你必需要有一个线程不停的尝试从网络链接中读取请求，接着要处理请求，最后还要返回响应给设备。

那么这种模式有什么缺点呢？

缺点是很显而易见的，假如说此时你有上百万个设备要跟你的系统进行链接，假设你的系统作了集群部署一共有100个服务实例，难道每一个服务实例要维持1万个链接支撑跟1万个设备的通讯？

若是这样的话，每一个服务实例不就是要维持1万个线程来维持1万个链接了吗？你们以为这个事儿靠谱吗？

根据线上的生产经验，通常4核8G的标准服务用的虚拟机，本身开辟的工做线程在一两百个就会让CPU负载很高了，最佳的建议就是在几十个工做线程就差很少。

因此要是指望每一个服务实例来维持上万个线程，那几乎是不可能的，因此这种模式最大的问题就在于这里，无法支撑大量链接。

（4）Kafka遇到的问题：应对大量客户端链接

实际上，对于大名鼎鼎的消息系统Kafka来讲，他也是会面对一样的问题，由于他须要应对大量的客户端链接。

有不少生产者和消费者都要跟Kafka创建相似上面的长链接，而后基于一个链接，一直不停的通讯。

举个例子，好比生产者须要经过一个链接，不停的发送数据给Kafka。而后Kafka也要经过这个链接不停的返回响应给生产者。

消费者也须要经过一个链接不停的从Kafka获取数据，Kafka须要经过这个链接不停的返回数据给消费者。

你们看下面的图，感觉一下Kafka的生产现场。

那假如Kafka就简单的按照这个架构来处理，若是你的公司里有几万几十万个的生产者或者消费者的服务实例，难道Kafka集群就要为了几万几十万个链接来维护这么多的线程吗？

一样，这是不现实的，由于线程是昂贵的资源，不可能在集群里使用那么多的线程。

（5）Kafka的架构实践：Reactor多路复用

针对这个问题，大名鼎鼎的Kafka采用的架构策略是Reactor多路复用模型。

简单来讲，就是搞一个acceptor线程，基于底层操做系统的支持，实现链接请求监听。

若是有某个设备发送了创建链接的请求过来，那么那个线程就把这个创建好的链接交给processor线程。

每一个processor线程会被分配N多个链接，一个线程就能够负责维持N多个链接，他一样会基于底层操做系统的支持监听N多链接的请求。

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

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

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

说了这么多，仍是来一张图，你们看下面的图，就能够理解上述整个过程了。

（6）优化后的架构是如何支撑大量链接的？

那么上面优化后的那套架构，是如何支撑大量链接的呢？

其实很简单。这里最关键的一个因素，就是processor线程是一我的维持N个线程，基于底层操做系统的特殊机制的支持，一我的能够监听N个链接的请求。

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

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

好比说按照100万链接来计算，若是有100台机器来处理，按照老的模式，每台机器须要维持1万个线程来处理1万个链接。

可是若是按照这种多路复用的模式，可能就好比10个processor + 40个线程的线程池，一共50个线程就能够上万链接。

在这种模式下，每台机器有限的线程数量能够抗住大量的链接。

所以实际上咱们在设计这种支撑大量链接的系统的时候，彻底能够参考这种架构，设计成多路复用的模式，用几十个线程处理成千上万个链接，最终实现百万链接的处理架构。

End

（封面,图源网络，侵权删除）

扫描下方二维码，备注：“资料”，获取更多“秘制” 精品学习资料

一大波微服务、分布式、高并发、高可用的原创系列文章正在路上

欢迎扫描下方二维码，持续关注：

石杉的架构笔记（id:shishan100）

十余年BAT架构经验倾囊相授