深入Netty逻辑架构,从Reactor线程模型开始(一)

简介: 深入Netty逻辑架构,从Reactor线程模型开始(一)

1.什么是Reactor线程模型?


先来回顾下我们在Netty系列的第2篇介绍的I/O线程模型,包括BIO、NIO、I/O多路复用、信号驱动IO、AIO。IO多路复用在Java中有专门的NIO包封装了相关的方法。


前面的文章也说过,使用Netty而不是直接使用Java NIO包,就是因为Netty帮我们封装了许多对NIO包的使用细节,做了许多优化。


其中非常著名的,就是Netty的「Reactor线程模型」。


前置知识如果还不太清楚,可以回头看看前面几篇文章:


《没搞清楚网络I/O模型?那怎么入门Netty》
《从网络I/O模型到Netty,先深入了解下I/O多路复用》
《从I/O多路复用到Netty,还要跨过Java NIO包》


Reactor模式 是一种「事件驱动」模式。


「Reactor线程模型」就是通过 单个线程 使用Java NIO包中的Selector的select()方法,进行监听。当获取到事件(如accept、read等)后,就会分配(dispatch)事件进行相应的事件处理(handle)。


如果要给 Reactor线程模型 下一个更明确的定义,应该是:


Reactor线程模式 = Reactor(I/O多路复用)+ 线程池


其中Reactor负责监听和分配事件,线程池负责处理事件。


然后,根据Reactor的数量和线程池的数量,又可以将Reactor分为三种模型


  • 单Reactor单线程模型 (固定大小为1的线程池)
  • 单Reactor多线程模型
  • 多Reactor多线程模型 (一般是主从2个Reactor)


1.1 单Reactor单线程模型


77.png


Reactor内部通过 selector 监听连接事件,收到事件后通过dispatch进行分发。


  • 如果是连接建立的事件,通过accept接受连接,并创建一个Handler来处理连接后续的各种事件。
  • 如果是读写事件,直接调用连接对应的Handler来处理,Handler完成 read => (decode => compute => encode) => send 的全部流程


这个过程中,无论是事件监听、事件分发、还是事件处理,都始终只有 一个线程 执行所有的事情。


缺点:
在请求过多时,会无法支撑。因为只有一个线程,无法发挥多核CPU性能。
而且一旦某个Handler发生阻塞,服务端就完全无法处理其他连接事件。


1.2 单Reactor多线程模型


为了提高性能,我们可以把复杂的事件处理handler交给线程池,那就可以演进为 「单Reactor多线程模型」 。


78.png


这种模型和第一种模型的主要区别是把业务处理从之前的单一线程脱离出来,换成线程池处理。


1)Reactor线程


通过select监听客户请求,如果是连接建立的事件,通过accept接受连接,并创建一个Handler来处理连接后续的读写事件。这里的Handler只负责响应事件、read和write事件,会将具体的业务处理交由Worker线程池处理。


只处理连接事件、读写事件。


2)Worker线程池


处理所有业务事件,包括(decode => compute => encode) 过程。


充分利用多核机器的资源,提高性能。


缺点:
在极个别特殊场景中,一个Reactor线程负责监听和处理所有的客户端连接可能会存在性能问题。例如并发百万客户端连接(双十一、春运抢票)


1.3 多Reactor多线程模型


为了充分利用多核能力,可以构建两个 Reactor,这就演进为 「主从Reactor线程模型」 。

79.png


1)主Reactor


主 Reactor 单独监听server socket,accept新连接,然后将建立的 SocketChannel 注册给指定的 从Reactor,


2)从Reactor


从Reactor 将连接加入到连接队列进行监听,并创建handler进行事件处理。执行事件的读写、分发,把业务处理就扔给worker线程池完成。


3)Worker线程池


处理所有业务事件,充分利用多核机器的资源,提高性能。


轻松处理百万并发。


缺点:
实现比较复杂。


不过有了Netty,一切都变得简单了。


Netty帮我们封装好了一切,可以快速使用主从Reactor线程模型(Netty4的实现上增加了无锁串行化设计),具体代码这里就不贴了,可以看看上一篇的Demo。


2. EventLoop、EventLoopGroup 怎么实现Reactor线程模型?


上面我们已经了解了Reactor线程模型,了解了它的核心就是:


Reactor线程模式 = Reactor(I/O多路复用)+ 线程池


它的运行模式包括四个步骤:


  • 连接注册:建立连接后,将channel注册到selector上
  • 事件轮询:selcetor上轮询(select()函数)获取已经注册的channel的所有I/O事件(多路复用)
  • 事件分发:把准备就绪的I/O事件分配到对应线程进行处理
  • 事件处理:每个worker线程执行事件任务


那这样的模型在Netty中具体怎么实现呢?


这就需要我们了解下EventLoop和EventLoopGroup了。


2.1 EventLoop是什么


EventLoop 不是Netty独有的,它本身是一个通用的 事件等待和处理的程序模型。主要用来解决多线程资源消耗高的问题。例如 Node.js 就采用了 EventLoop 的运行机制。


那么,在Netty中,EventLoop是什么呢?


  • 一个Reactor模型的事件处理器。
  • 单独一个线程。
  • 一个EventLoop内部会维护一个selector和一个「taskQueue任务队列」,分别负责处理 「I/O事件」 和 「任务」。


「taskQueue任务队列」是多生产者单消费者队列,在多线程并发添加任务时,可以保证线程安全。


「I/O事件」即selectionKey中的事件,如accept、connect、read、write等;


「任务」包括 普通任务、定时任务等。


  • 普通任务:通过 NioEventLoop 的 execute() 方法向任务队列 taskQueue 中添加任务。例如 Netty 在写数据时会封装 WriteAndFlushTask 提交给 taskQueue。
  • 定时任务:通过调用 NioEventLoop 的 schedule() 方法向 定时任务队列 scheduledTaskQueue 添加一个定时任务,用于周期性执行该任务(如心跳消息发送等)。定时任务队列的任务 到了执行时间后,会合并到 普通任务 队列中进行真正执行。


一图胜千言:

80.png


EventLoop单线程运行,循环往复执行三个动作:


  • selector事件轮询
  • I/O事件处理
  • 任务处理


2.2 EventLoopGroup是什么


EventLoopGroup比较简单,可以简单理解为一个“EventLoop线程池”。

81.png


Tips:

监听一个端口,只会绑定到 BossEventLoopGroup 中的一个 Eventloop,所以, BossEventLoopGroup 配置多个线程也无用,除非你同时监听多个端口。


2.3 具体实现


Netty可以通过简单配置,支持单Reactor单线程模型 、单Reactor多线程模型 、多Reactor多线程模型。


我们以 「多Reactor多线程模型」 为例,来看看Netty是如何通过EventLoop来实现的。


还是一图胜千言:


82.png


我们结合Reactor线程模型的四个步骤来梳理一下:


1)连接注册


master EventLoopGroup中有一个EventLoop,绑定某个特定端口进行监听。


一旦有新的连接进来触发accept类型事件,就会在当前EventLoop的I/O事件处理阶段,将这个连接分配给slave EventLoopGroup中的某一个EventLoop,进行后续 事件的监听。


2)事件轮询


slave EventLoopGroup中的EventLoop,会通过selcetor对绑定到自身的channel进行轮询,获取已经注册的channel的所有I/O事件(多路复用)。


当然,EventLoopGroup中会有 多个EventLoop 运行,各自循环处理。具体EventLoop数量是由 用户指定的线程数 或者 默认为核数的2倍。


3)事件分发


当slave EventLoopGroup中的EventLoop获取到I/O事件后,会在EventLoop的 I/O事件处理(processSelectedKeys) 阶段分发给对应ChannelPipeline进行处理。


注意,仍然在当前线程进行串行处理


4)事件处理


在ChannelPipeline中对I/O事件进行处理。


I/O事件处理完后,EventLoop在 任务处理(runAllTasks) 阶段,对队列中的任务进行消费处理。


至此,我们就能完全梳理清楚EventLoopGroup/EventLoop 和 Reactor线程模型的关系了。


咦,好像有什么地方不对劲?


没错,细心的朋友可能会发现,slave EventLoopGroup中并不是


一个selector + 线程池


而是有多个EventLoop组成的


多selector + 多个单线程


这是为什么呢?


那就得继续深入了解下Netty4的线程模型优化了。

目录
相关文章
|
机器学习/深度学习 人工智能 监控
大型动作模型LAM:让企业重复任务实现80%效率提升的AI技术架构与实现方案
大型动作模型(LAMs)作为人工智能新架构,融合神经网络与符号逻辑,实现企业重复任务的自动化处理。通过神经符号集成、动作执行管道、模式学习、任务分解等核心技术,系统可高效解析用户意图并执行复杂操作,显著提升企业运营效率并降低人工成本。其自适应学习能力与上下文感知机制,使自动化流程更智能、灵活,为企业数字化转型提供坚实支撑。
728 0
大型动作模型LAM:让企业重复任务实现80%效率提升的AI技术架构与实现方案
|
存储 BI Shell
Doris基础-架构、数据模型、数据划分
Apache Doris 是一款高性能、实时分析型数据库,基于MPP架构,支持高并发查询与复杂分析。其前身是百度的Palo项目,现为Apache顶级项目。Doris适用于报表分析、数据仓库构建、日志检索等场景,具备存算一体与存算分离两种架构,灵活适应不同业务需求。它提供主键、明细和聚合三种数据模型,便于高效处理更新、存储与统计汇总操作,广泛应用于大数据分析领域。
1423 2
|
数据采集 机器学习/深度学习 搜索推荐
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
MIT与丰田研究院研究发现,扩散模型的“局部性”并非源于网络架构的精巧设计,而是自然图像统计规律的产物。通过线性模型仅学习像素相关性,即可复现U-Net般的局部敏感模式,揭示数据本身蕴含生成“魔法”。
442 3
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
|
11月前
|
设计模式 缓存 安全
【JUC】(6)带你了解共享模型之 享元和不可变 模型并初步带你了解并发工具 线程池Pool,文章内还有饥饿问题、设计模式之工作线程的解决于实现
JUC专栏第六篇,本文带你了解两个共享模型:享元和不可变 模型,并初步带你了解并发工具 线程池Pool,文章中还有解决饥饿问题、设计模式之工作线程的实现
736 2
|
11月前
|
机器学习/深度学习 存储 缓存
115_LLM基础模型架构设计:从Transformer到稀疏注意力
大型语言模型(LLM)的架构设计是其性能的核心决定因素。从2017年Transformer架构的提出,到如今的稀疏注意力和混合专家模型,LLM架构经历了快速的演进。本文将全面探讨LLM基础架构的设计原理,深入分析Transformer的核心机制,详细介绍稀疏注意力、MoE等创新架构,并展望未来架构发展方向。通过数学推导和实践案例,为构建高效、强大的LLM提供全面指导。
1344 0
|
11月前
|
机器学习/深度学习 自然语言处理 算法
48_动态架构模型:NAS在LLM中的应用
大型语言模型(LLM)在自然语言处理领域的突破性进展,很大程度上归功于其庞大的参数量和复杂的网络架构。然而,随着模型规模的不断增长,计算资源消耗、推理延迟和部署成本等问题日益凸显。如何在保持模型性能的同时,优化模型架构以提高效率,成为2025年大模型研究的核心方向之一。神经架构搜索(Neural Architecture Search, NAS)作为一种自动化的网络设计方法,正在为这一挑战提供创新性解决方案。本文将深入探讨NAS技术如何应用于LLM的架构优化,特别是在层数与维度调整方面的最新进展,并通过代码实现展示简单的NAS实验。
517 0
|
编解码 文字识别 自然语言处理
Dots.ocr:告别复杂多模块架构,1.7B参数单一模型统一处理所有OCR任务22
Dots.ocr 是一款仅1.7B参数的视觉语言模型,正在重塑文档处理技术。它将布局检测、文本识别、阅读顺序理解和数学公式解析等任务统一于单一架构,突破传统OCR多模块流水线的限制。在多项基准测试中,其表现超越大参数模型,展现出“小而精”的实用价值,标志着OCR技术向高效、统一、灵活方向演进。
1118 0
Dots.ocr:告别复杂多模块架构,1.7B参数单一模型统一处理所有OCR任务22
|
存储 人工智能 调度
上海创智学院联合无问芯穹发布Megrez2.0,本征架构突破端模型不可能三角,以终端算力撬动云端智能
终端是实现数字智能和生命智能自由交互的重要接口,持续帮助人类拓展生产能力的边界。当下,终端智能面临着“能效-空间-智能”的不可能三角:以DeepSeek-R1为例,其参数规模高达6710亿,超出了大部分笔记本电脑的内存容量;即使勉强在一台笔记本电脑上成功运行满血版模型,理论上坚持不到9分钟就会耗尽电池;如果通过蒸馏,将满血版模型压缩到更小尺寸,此时的精度损失又可能满足不了智能水平的要求。
352 0
上海创智学院联合无问芯穹发布Megrez2.0,本征架构突破端模型不可能三角,以终端算力撬动云端智能
|
存储 人工智能 前端开发
Google揭秘Agent架构三大核心:工具、模型与编排层实战指南
本文为Google发布的Agent白皮书全文翻译。本文揭示了智能体如何突破传统AI边界,通过模型、工具与编排层的三位一体架构,实现自主推理与现实交互。它不仅详解了ReAct、思维树等认知框架的运作逻辑,更通过航班预订、旅行规划等案例,展示了智能体如何调用Extensions、Functions和Data Stores,将抽象指令转化为真实世界操作。文中提出的“智能体链式组合”概念,预示了未来多智能体协作解决复杂问题的革命性潜力——这不仅是技术升级,更是AI赋能产业的范式颠覆。
3531 1
|
人工智能 监控 API
MCP中台,究竟如何实现多模型、多渠道、多环境的统一管控?如何以MCP为核心设计AI应用架构?
本文产品专家三桥君探讨了以 MCP 为核心的 AI 应用架构设计,从统一接入、数据管理、服务编排到部署策略等维度,系统化分析了 AI 落地的关键环节。重点介绍了 API 网关的多终端适配、数据异步处理流程、LLM 服务的灰度发布与 Fallback 机制,以及 MCP Server 作为核心枢纽的调度功能。同时对比了公有云 API、私有化 GPU 和无服务器部署的适用场景,强调通过全链路监控与智能告警保障系统稳定性。该架构为企业高效整合 AI 能力提供了实践路径,平衡性能、成本与灵活性需求。
929 0