深入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的线程模型优化了。

目录
相关文章
|
4月前
|
编解码 网络协议 API
Netty运行原理问题之Netty的主次Reactor多线程模型工作的问题如何解决
Netty运行原理问题之Netty的主次Reactor多线程模型工作的问题如何解决
|
4月前
|
设计模式 架构师 数据建模
架构师必备底层逻辑:设计与建模的技术深度探索
【8月更文挑战第13天】在软件开发的浩瀚星海中,架构师如同星辰指引,他们不仅规划着系统的蓝图,更在底层逻辑上精雕细琢,确保系统的稳健与高效。其中,“设计与建模”作为架构师的核心能力之一,是连接业务需求与技术实现的桥梁。本文将深入探讨架构师在设计与建模过程中的关键思维与实践方法,为工作学习中的技术同仁提供一份宝贵的干货分享。
65 3
|
4月前
|
开发工具 Android开发
Android项目架构设计问题之SDK内部减少每次回调时的冗余判断逻辑如何解决
Android项目架构设计问题之SDK内部减少每次回调时的冗余判断逻辑如何解决
47 0
|
4月前
|
Android开发 iOS开发
Android项目架构设计问题之将隐式跳转的逻辑进行抽象和封装如何解决
Android项目架构设计问题之将隐式跳转的逻辑进行抽象和封装如何解决
53 0
|
5月前
|
监控 安全 前端开发
交易所系统开发(源码正式版)/需求逻辑/玩法详情/规则架构
交易所源码开发是指基于特定的需求和要求,从头开始构建一个自定义的交易所平台的开发过程。这种开发可以包括以下几个关键方面:
|
5月前
|
运维 Java Docker
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
|
21天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
1月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
43 3
|
1月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
20天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
141 68
从单体到微服务:如何借助 Spring Cloud 实现架构转型