欢迎关注个人公众号：石杉的架构笔记（ID:shishan100）
周一至周五早8点半！精品技术文章准时送上！
精品学习资料获取通道，参见文末
目录
1、到底什么是连接？
2、为什么每次发送请求都要建立连接？
3、长连接模式下需要耗费大量资源
4、Kafka遇到的问题：应对大量客户端连接
5、Kafka的架构实践：Reactor多路复用
6、优化后的架构是如何支撑大量连接的
“ 这篇文章，给大家聊聊：如果你设计一个系统需要支撑百万用户连接，应该如何来设计其高并发请求处理架构？
（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架构经验倾囊相授
推荐阅读：
1、拜托！面试请不要再问我Spring Cloud底层原理
2、【双11狂欢的背后】微服务注册中心如何承载大型系统的千万级访问？
3、【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战
4、微服务架构如何保障双11狂欢下的99.99%高可用
5、兄弟，用大白话告诉你小白都能听懂的Hadoop架构原理
6、大规模集群下Hadoop NameNode如何承载每秒上千次的高并发访问
7、【性能优化的秘密】Hadoop如何将TB级大文件的上传性能优化上百倍
8、拜托，面试请不要再问我TCC分布式事务的实现原理！
9、【坑爹呀！】最终一致性分布式事务如何保障实际生产中99.99%高可用？
10、拜托，面试请不要再问我Redis分布式锁的实现原理！
11、【眼前一亮！】看Hadoop底层算法如何优雅的将大规模集群性能提升10倍以上？
12、亿级流量系统架构之如何支撑百亿级数据的存储与计算
13、亿级流量系统架构之如何设计高容错分布式计算系统
14、亿级流量系统架构之如何设计承载百亿流量的高性能架构
15、亿级流量系统架构之如何设计每秒十万查询的高并发架构
16、亿级流量系统架构之如何设计全链路99.99%高可用架构
17、七张图彻底讲清楚ZooKeeper分布式锁的实现原理
18、大白话聊聊Java并发面试问题之volatile到底是什么？
19、大白话聊聊Java并发面试问题之Java 8如何优化CAS性能？
20、大白话聊聊Java并发面试问题之谈谈你对AQS的理解？
21、大白话聊聊Java并发面试问题之公平锁与非公平锁是啥？
22、大白话聊聊Java并发面试问题之微服务注册中心的读写锁优化
23、互联网公司的面试官是如何360°无死角考察候选人的？（上篇）
24、互联网公司面试官是如何360°无死角考察候选人的？（下篇）
25、Java进阶面试系列之一：哥们，你们的系统架构中为什么要引入消息中间件？
26、【Java进阶面试系列之二】：哥们，那你说说系统架构引入消息中间件有什么缺点？
27、【行走的Offer收割机】记一位朋友斩获BAT技术专家Offer的面试经历
28、【Java进阶面试系列之三】哥们，消息中间件在你们项目里是如何落地的？
29、【Java进阶面试系列之四】扎心！线上服务宕机时，如何保证数据100%不丢失？
30、一次JVM FullGC的背后，竟隐藏着惊心动魄的线上生产事故！
31、【高并发优化实践】10倍请求压力来袭，你的系统会被击垮吗？
32、【Java进阶面试系列之五】消息中间件集群崩溃，如何保证百万生产数据不丢失？
33、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（上）？
34、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（中）？
35、亿级流量系统架构之如何在上万并发场景下设计可扩展架构（下）？
36、亿级流量架构第二弹：你的系统真的无懈可击吗？
37、亿级流量系统架构之如何保证百亿流量下的数据一致性（上）
38、亿级流量系统架构之如何保证百亿流量下的数据一致性（中）？
39、亿级流量系统架构之如何保证百亿流量下的数据一致性（下）？
40、互联网面试必杀：如何保证消息中间件全链路数据100%不丢失（1）
41、互联网面试必杀：如何保证消息中间件全链路数据100%不丢失（2）
42、面试大杀器：消息中间件如何实现消费吞吐量的百倍优化？
43、高并发场景下，如何保证生产者投递到消息中间件的消息不丢失？
44、兄弟，用大白话给你讲小白都能看懂的分布式系统容错架构
45、从团队自研的百万并发中间件系统的内核设计看Java并发性能优化
46、【非广告，纯干货】英语差的程序员如何才能无障碍阅读官方文档？
47、如果20万用户同时访问一个热点缓存，如何优化你的缓存架构？
48、【非广告，纯干货】中小公司的Java工程师应该如何逆袭冲进BAT？
49、拜托，面试请不要再问我分布式搜索引擎的架构原理！
50、【金三银四跳槽季】Java工程师如何在1个月内做好面试准备？
51、【offer收割机必备】我简历上的Java项目都好low，怎么办？
52、【offer去哪了】我一连面试了十个Java岗，统统石沉大海！
53、高阶Java开发必备：分布式系统的唯一id生成算法你了解吗？
54、支撑日活百万用户的高并发系统，应该如何设计其数据库架构？
55、尴尬了！Spring Cloud微服务注册中心Eureka 2.x停止维护了咋办？
56、【Java高阶必备】如何优化Spring Cloud微服务注册中心架构？
57、面试官：消息中间件如何实现每秒几十万的高并发写入？
58、【非广告，纯干货】三四十岁的大龄程序员，应该如何保持自己的职场竞争力？
作者：石杉的架构笔记
链接：https://juejin.im/post/5c6a9f25518825787e69e70a
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。