高性能网络编程(六)：一文读懂高性能网络编程中的线程模型

1、前言

本文接上篇《高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型》。

随着互联网的发展，面对海量用户高并发业务，传统的阻塞式的服务端架构模式已经无能为力。本文（和上篇《高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型》）旨在为大家提供有用的高性能网络编程的I/O模型概览以及网络服务进程模型的比较，以揭开设计和实现高性能网络架构的神秘面纱。

另外，作者的其它文章《新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析》、《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》，也值得一读，推荐一并阅读之。

2、关于作者

陈彩华（caison）：主要从事服务端开发、需求分析、系统设计、优化重构工作，主要开发语言是 Java，现任广州贝聊服务端研发工程师。

关于广州贝聊：

广州市贝聊信息科技有限公司成立于2013年8月21日，是一家专注于搭建幼儿园家园共育平台的信息科技公司。

公司产品“贝聊”是中国幼儿园家长工作平台，致力于通过互联网产品及定制化解决方案，帮助幼儿园解决展示、通知、沟通等家长工作中的痛点，促进家园关系和谐。贝聊是威创股份（A股幼教第一股）、清华启迪、网易联手投资的唯一品牌。

截止目前，“贝聊”已覆盖全国31省份的5万所幼儿园及机构，注册用户超过1000万，用户次月留存率高达74%，复合增长率为18.94%，领跑全行业。

3、C10K问题系列文章

本文是C10K问题系列文章中的第6篇，总目录如下：

• 《高性能网络编程(一)：单台服务器并发TCP连接数到底可以有多少》
• 《高性能网络编程(二)：上一个10年，著名的C10K并发连接问题》
• 《高性能网络编程(三)：下一个10年，是时候考虑C10M并发问题了》
• 《高性能网络编程(四)：从C10K到C10M高性能网络应用的理论探索》
• 《高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型》
• 《高性能网络编程(六)：一文读懂高性能网络编程中的线程模型》（本文）
• 《高性能网络编程(七)：到底什么是高并发？一文即懂！》
• 《高性能网络编程经典：《The C10K problem(英文)》[附件下载]》
  

4、线程模型

上篇《高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型》介绍完服务器如何基于 I/O 模型管理连接，获取输入数据，下面将介绍基于进程/线程模型，服务器如何处理请求。

值得说明的是，具体选择线程还是进程，更多是与平台及编程语言相关。

例如 C 语言使用线程和进程都可以(例如 Nginx 使用进程，Memcached 使用线程)，Java 语言一般使用线程(例如 Netty)，为了描述方便，下面都使用线程来进行描述。

5、线程模型1：传统阻塞 I/O 服务模型

特点：

• 1）采用阻塞式 I/O 模型获取输入数据；
• 2）每个连接都需要独立的线程完成数据输入，业务处理，数据返回的完整操作。
  

存在问题：

• 1）当并发数较大时，需要创建大量线程来处理连接，系统资源占用较大；
• 2）连接建立后，如果当前线程暂时没有数据可读，则线程就阻塞在 Read 操作上，造成线程资源浪费。
  

6、线程模型2：Reactor 模式

6.1基本介绍

针对传统阻塞 I/O 服务模型的 2 个缺点，比较常见的有如下解决方案：

• 1）基于 I/O 复用模型：多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理；
• 2）基于线程池复用线程资源：不必再为每个连接创建线程，将连接完成后的业务处理任务分配给线程进行处理，一个线程可以处理多个连接的业务。
  

I/O 复用结合线程池，这就是 Reactor 模式基本设计思想，如下图：


Reactor 模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。

服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor 模式也叫 Dispatcher 模式。

即 I/O 多路复用统一监听事件，收到事件后分发(Dispatch 给某进程)，是编写高性能网络服务器的必备技术之一。

Reactor 模式中有 2 个关键组成：

• 1）Reactor：Reactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对 IO 事件做出反应。 它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人；
• 2）Handlers：处理程序执行 I/O 事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际官员。Reactor 通过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操作。
  

根据 Reactor 的数量和处理资源池线程的数量不同，有 3 种典型的实现：

• 1）单 Reactor 单线程；
• 2）单 Reactor 多线程；
• 3）主从 Reactor 多线程。
  

下面详细介绍这 3 种实现方式。

6.2单 Reactor 单线程

其中，Select 是前面 I/O 复用模型介绍的标准网络编程 API，可以实现应用程序通过一个阻塞对象监听多路连接请求，其他方案示意图类似。

方案说明：

• 1）Reactor 对象通过 Select 监控客户端请求事件，收到事件后通过 Dispatch 进行分发；
• 2）如果是建立连接请求事件，则由 Acceptor 通过 Accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后的后续业务处理；
• 3）如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应；
• 4）Handler 会完成 Read→业务处理→Send 的完整业务流程。
  

优点：模型简单，没有多线程、进程通信、竞争的问题，全部都在一个线程中完成。
缺点：性能问题，只有一个线程，无法完全发挥多核 CPU 的性能。Handler 在处理某个连接上的业务时，整个进程无法处理其他连接事件，很容易导致性能瓶颈。

可靠性问题，线程意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。

使用场景：客户端的数量有限，业务处理非常快速，比如 Redis，业务处理的时间复杂度 O(1)。

6.3单 Reactor 多线程

方案说明：

• 1）Reactor 对象通过 Select 监控客户端请求事件，收到事件后通过 Dispatch 进行分发；
• 2）如果是建立连接请求事件，则由 Acceptor 通过 Accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后续的各种事件；
• 3）如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应；
• 4）Handler 只负责响应事件，不做具体业务处理，通过 Read 读取数据后，会分发给后面的 Worker 线程池进行业务处理；
• 5）Worker 线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给 Handler 进行处理；
• 6）Handler 收到响应结果后通过 Send 将响应结果返回给 Client。
  

优点：可以充分利用多核 CPU 的处理能力。
缺点：多线程数据共享和访问比较复杂；Reactor 承担所有事件的监听和响应，在单线程中运行，高并发场景下容易成为性能瓶颈。

6.4主从 Reactor 多线程

针对单 Reactor 多线程模型中，Reactor 在单线程中运行，高并发场景下容易成为性能瓶颈，可以让 Reactor 在多线程中运行。

方案说明：

• 1）Reactor 主线程 MainReactor 对象通过 Select 监控建立连接事件，收到事件后通过 Acceptor 接收，处理建立连接事件；
• 2）Acceptor 处理建立连接事件后，MainReactor 将连接分配 Reactor 子线程给 SubReactor 进行处理；
• 3）SubReactor 将连接加入连接队列进行监听，并创建一个 Handler 用于处理各种连接事件；
• 4）当有新的事件发生时，SubReactor 会调用连接对应的 Handler 进行响应；
• 5）Handler 通过 Read 读取数据后，会分发给后面的 Worker 线程池进行业务处理；
• 6）Worker 线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给 Handler 进行处理；
• 7）Handler 收到响应结果后通过 Send 将响应结果返回给 Client。
  

优点：父线程与子线程的数据交互简单职责明确，父线程只需要接收新连接，子线程完成后续的业务处理。

父线程与子线程的数据交互简单，Reactor 主线程只需要把新连接传给子线程，子线程无需返回数据。

这种模型在许多项目中广泛使用，包括 Nginx 主从 Reactor 多进程模型，Memcached 主从多线程，Netty 主从多线程模型的支持。

6.5小结

3 种模式可以用个比喻来理解：（餐厅常常雇佣接待员负责迎接顾客，当顾客入坐后，侍应生专门为这张桌子服务）

• 1）单 Reactor 单线程，接待员和侍应生是同一个人，全程为顾客服务；
• 2）单 Reactor 多线程，1 个接待员，多个侍应生，接待员只负责接待；
• 3）主从 Reactor 多线程，多个接待员，多个侍应生。
  

Reactor 模式具有如下的优点：

• 1）响应快，不必为单个同步时间所阻塞，虽然 Reactor 本身依然是同步的；
• 2）编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
• 3）可扩展性，可以方便的通过增加 Reactor 实例个数来充分利用 CPU 资源；
• 4）可复用性，Reactor 模型本身与具体事件处理逻辑无关，具有很高的复用性。
  

7、线程模型2：Proactor 模型

在 Reactor 模式中，Reactor 等待某个事件或者可应用或者操作的状态发生（比如文件描述符可读写，或者是 Socket 可读写）。

然后把这个事件传给事先注册的 Handler（事件处理函数或者回调函数），由后者来做实际的读写操作。

其中的读写操作都需要应用程序同步操作，所以 Reactor 是非阻塞同步网络模型。

如果把 I/O 操作改为异步，即交给操作系统来完成就能进一步提升性能，这就是异步网络模型 Proactor。



Proactor 是和异步 I/O 相关的，详细方案如下：

• 1）Proactor Initiator 创建 Proactor 和 Handler 对象，并将 Proactor 和 Handler 都通过 AsyOptProcessor（Asynchronous Operation Processor）注册到内核；
• 2）AsyOptProcessor 处理注册请求，并处理 I/O 操作；
• 3）AsyOptProcessor 完成 I/O 操作后通知 Proactor；
• 4）Proactor 根据不同的事件类型回调不同的 Handler 进行业务处理；
• 5）Handler 完成业务处理。
  

可以看出 Proactor 和 Reactor 的区别：

• 1）Reactor 是在事件发生时就通知事先注册的事件（读写在应用程序线程中处理完成）；
• 2）Proactor 是在事件发生时基于异步 I/O 完成读写操作（由内核完成），待 I/O 操作完成后才回调应用程序的处理器来进行业务处理。
  

理论上 Proactor 比 Reactor 效率更高，异步 I/O 更加充分发挥 DMA(Direct Memory Access，直接内存存取)的优势。

但是Proactor有如下缺点：

• 1）编程复杂性，由于异步操作流程的事件的初始化和事件完成在时间和空间上都是相互分离的，因此开发异步应用程序更加复杂。应用程序还可能因为反向的流控而变得更加难以 Debug；
• 2）内存使用，缓冲区在读或写操作的时间段内必须保持住，可能造成持续的不确定性，并且每个并发操作都要求有独立的缓存，相比 Reactor 模式，在 Socket 已经准备好读或写前，是不要求开辟缓存的；
• 3）操作系统支持，Windows 下通过 IOCP 实现了真正的异步 I/O，而在 Linux 系统下，Linux 2.6 才引入，目前异步 I/O 还不完善。
  

因此在 Linux 下实现高并发网络编程都是以 Reactor 模型为主。

（本文上篇为《高性能网络编程(五)：一文读懂高性能网络编程中的I/O模型》，您也可前往阅读）

附录：更多网络编程精华文章

[1] 网络编程基础资料：
《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《技术往事：改变世界的TCP/IP协议（珍贵多图、手机慎点）》
《通俗易懂-深入理解TCP协议（上）：理论基础》
《通俗易懂-深入理解TCP协议（下）：RTT、滑动窗口、拥塞处理》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《UDP中一个包的大小最大能多大？》
《P2P技术详解(一)：NAT详解——详细原理、P2P简介》
《P2P技术详解(二)：P2P中的NAT穿越(打洞)方案详解》
《P2P技术详解(三)：P2P技术之STUN、TURN、ICE详解》
《通俗易懂：快速理解P2P技术中的NAT穿透原理》
《不为人知的网络编程(一)：浅析TCP协议中的疑难杂症(上篇)》
《不为人知的网络编程(二)：浅析TCP协议中的疑难杂症(下篇)》
《不为人知的网络编程(三)：关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT》
《不为人知的网络编程(四)：深入研究分析TCP的异常关闭》
《不为人知的网络编程(五)：UDP的连接性和负载均衡》
《不为人知的网络编程(六)：深入地理解UDP协议并用好它》
《不为人知的网络编程(七)：如何让不可靠的UDP变的可靠？》
《网络编程懒人入门(一)：快速理解网络通信协议（上篇）》
《网络编程懒人入门(二)：快速理解网络通信协议（下篇）》
《网络编程懒人入门(三)：快速理解TCP协议一篇就够》
《网络编程懒人入门(四)：快速理解TCP和UDP的差异》
《网络编程懒人入门(五)：快速理解为什么说UDP有时比TCP更有优势》
《网络编程懒人入门(六)：史上最通俗的集线器、交换机、路由器功能原理入门》
《网络编程懒人入门(七)：深入浅出，全面理解HTTP协议》
《网络编程懒人入门(八)：手把手教你写基于TCP的Socket长连接》
《网络编程懒人入门(九)：通俗讲解，有了IP地址，为何还要用MAC地址？》
《技术扫盲：新一代基于UDP的低延时网络传输层协议——QUIC详解》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《聊聊iOS中网络编程长连接的那些事》
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
《从HTTP/0.9到HTTP/2：一文读懂HTTP协议的历史演变和设计思路》
《脑残式网络编程入门(一)：跟着动画来学TCP三次握手和四次挥手》
《脑残式网络编程入门(二)：我们在读写Socket时，究竟在读写什么？》
《脑残式网络编程入门(三)：HTTP协议必知必会的一些知识》
《脑残式网络编程入门(四)：快速理解HTTP/2的服务器推送(Server Push)》
《脑残式网络编程入门(五)：每天都在用的Ping命令，它到底是什么？》
《脑残式网络编程入门(六)：什么是公网IP和内网IP？NAT转换又是什么鬼？》
《以网游服务端的网络接入层设计为例，理解实时通信的技术挑战》
《迈向高阶：优秀Android程序员必知必会的网络基础》
《全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等》
《美图App的移动端DNS优化实践：HTTPS请求耗时减小近半》
《Android程序员必知必会的网络通信传输层协议——UDP和TCP》
《IM开发者的零基础通信技术入门(一)：通信交换技术的百年发展史(上)》
《IM开发者的零基础通信技术入门(二)：通信交换技术的百年发展史(下)》
《IM开发者的零基础通信技术入门(三)：国人通信方式的百年变迁》
《IM开发者的零基础通信技术入门(四)：手机的演进，史上最全移动终端发展史》
《IM开发者的零基础通信技术入门(五)：1G到5G，30年移动通信技术演进史》
《IM开发者的零基础通信技术入门(六)：移动终端的接头人——“基站”技术》
《IM开发者的零基础通信技术入门(七)：移动终端的千里马——“电磁波”》
《IM开发者的零基础通信技术入门(八)：零基础，史上最强“天线”原理扫盲》
《IM开发者的零基础通信技术入门(九)：无线通信网络的中枢——“核心网”》
《IM开发者的零基础通信技术入门(十)：零基础，史上最强5G技术扫盲》
《IM开发者的零基础通信技术入门(十一)：为什么WiFi信号差？一文即懂！》
《IM开发者的零基础通信技术入门(十二)：上网卡顿？网络掉线？一文即懂！》
>> 更多同类文章 ……

[2] NIO高性能异步网络编程资料：
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《有关“为何选择Netty”的11个疑问及解答》
《开源NIO框架八卦——到底是先有MINA还是先有Netty?》
《选Netty还是Mina：深入研究与对比（一）》
《选Netty还是Mina：深入研究与对比（二）》
《NIO框架入门(一)：服务端基于Netty4的UDP双向通信Demo演示》
《NIO框架入门(二)：服务端基于MINA2的UDP双向通信Demo演示》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
《Netty 4.x学习（一）：ByteBuf详解》
《Netty 4.x学习（二）：Channel和Pipeline详解》
《Netty 4.x学习（三）：线程模型详解》
《Apache Mina框架高级篇（一）：IoFilter详解》
《Apache Mina框架高级篇（二）：IoHandler详解》
《MINA2 线程原理总结（含简单测试实例）》
《Apache MINA2.0 开发指南（中文版）[附件下载]》
《MINA、Netty的源代码（在线阅读版）已整理发布》
《解决MINA数据传输中TCP的粘包、缺包问题（有源码）》
《解决Mina中多个同类型Filter实例共存的问题》
《实践总结：Netty3.x升级Netty4.x遇到的那些坑（线程篇）》
《实践总结：Netty3.x VS Netty4.x的线程模型》
《详解Netty的安全性：原理介绍、代码演示（上篇）》
《详解Netty的安全性：原理介绍、代码演示（下篇）》
《详解Netty的优雅退出机制和原理》
《NIO框架详解：Netty的高性能之道》
《Twitter：如何使用Netty 4来减少JVM的GC开销（译文）》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《Netty干货分享：京东京麦的生产级TCP网关技术实践总结》
《新手入门：目前为止最透彻的的Netty高性能原理和框架架构解析》
>> 更多同类文章 ……

学习了，我理解的时候总是把io模型和线程模型混为一谈，好文章，赞!!!!

文章写的好，但是点看法和你的不同。我认为不应该叫线程模型。而是叫做程序模型，或者程序模式。因为这个模型几乎就是一个程序的框架了，不单单是描述怎么分配线程。

引用：mili 发表于 2019-01-21 21:30
文章写的好，但是点看法和你的不同。我认为不应该叫线程模型。而是叫做程序模型，或者程序模式。因为这个模 ...

是的，你说的有道理，但确实没有办法用一个简单的词准确地表述出来。你说的程序模式又太生硬，等于没解释，读的人还是会可能会觉得不明觉历。

讲的精辟， 配上图理解起来更快，给楼主点赞

好文章，感觉自己太晚知道这个网站了，我要好好学习！！

引用：David_Z 发表于 2019-03-18 15:46
好文章，感觉自己太晚知道这个网站了，我要好好学习！！

看完线程再看IO模型，我感觉我有点蒙圈了。

引用：云水 发表于 2019-04-13 10:14
看完线程再看IO模型，我感觉我有点蒙圈了。

那表示你还有进步的空间，好事啊

原来reactor还有异步模式的

如果worker线程池被全部占用时，handeler处理也会积压，这种情况改怎么办？

引用：guoqi233 发表于 2019-06-26 17:49
如果worker线程池被全部占用时，handeler处理也会积压，这种情况改怎么办？

这就直接到达頩颈上限了，代码和业务都需要优化了。。

如此优秀

有没有实际的代码？可以参考一下

reactor 主从模式 解释很懵  想从代码上理解, 也还是懵的:
1）Reactor 主线程 MainReactor 对象通过 Select 监控建立连接事件，收到事件后通过 Acceptor 接收，处理建立连接事件；
2）Acceptor 处理建立连接事件后，MainReactor 将连接分配 Reactor 子线程给 SubReactor 进行处理；  
3）SubReactor 将连接加入连接队列进行监听，并创建一个 Handler 用于处理各种连接事件；
4）当有新的事件发生时，SubReactor 会调用连接对应的 Handler 进行响应；
5）Handler 通过 Read 读取数据后，会分发给后面的 Worker 线程池进行业务处理；
6）Worker 线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给 Handler 进行处理；
7）Handler 收到响应结果后通过 Send 将响应结果返回给 Client。

前三步一直理解不了，请问 还有其他文章解释这段的吗？  多谢了

引用：JackJiang 发表于 2019-06-26 18:57
这就直接到达頩颈上限了，代码和业务都需要优化了。。

nginx反向代理+横向扩容  ？

引用：echo_no7 发表于 2019-12-30 17:51
reactor 主从模式 解释很懵  想从代码上理解, 也还是懵的:
1）Reactor 主线程 MainReactor 对象通过 Selec ...

建议你看下epoll编程示例就会清楚了，我跟你一样，刚看也蒙蒙的

“Reactor 是非阻塞同步网络模型”， 这个论述是不是有问题，reactor也是阻塞io，应该多路复用，多个连接阻塞在同一个阻塞对象上

引用：zhangjian2 发表于 2020-06-23 09:34
“Reactor 是非阻塞同步网络模型”， 这个论述是不是有问题，reactor也是阻塞io，应该多路复用，多个连接阻 ...

你说的好绕

写的不错