netty源码分析(七)Acceptor与Dispatcher角色分析

理解Reactor模式的另外一篇文章是一篇论文:《reactor-siemens》,论文的环境是日志服务器的例子:
这里写图片描述
客户端将日志发送到日志服务器,日志服务器将日志通过各种设备输出。
意图:
The Reactor design pattern handles service requests that are
delivered concurrently to an application by one or more
clients. Each service in an application may consist of
serveral methods and is represented by a separate event handler
that is responsible for dispatching service-specific requests.
Dispatching of event handlers is performed by an initiation
dispatcher, which manages the registered event handlers.
Demultiplexing of service requests is performed by a
synchronous event demultiplexer.
Reactor 设计模式是为了处理由一个或多个客户端向一个应用发送的请求,应用中的每个服务有单独的时间处理器组成,事件处理器的作用是特定服务的请求进行分发,时间处理器的分发是由initiation dispatcher来进行,initiation dispatcher会管理诸多的事件处理器,服务请求的分离是由同步的事件分离器处理。

我们拿出来论文的核心知识点说一下:
这里写图片描述

图A是初始化的过程:
1. The logging server (1) registers the Logging Acceptor with the Initiation Dispatcher to handle connection requests;
日志服务通过初始化分发器注册到日志Acceptor 上去,用来处理连接请求。
2. The logging server invokes the handle events method (2) of the Initiation Dispatcher;
日志服务器调用初始化分发器的处理事件方法。
3. The Initiation Dispatcher invokes the synchronous event demultiplexing select (3) operation to wait for connection requests or logging data to arrive;
初始化分发器通用同步的事件分离方法(select())来等待连接请求或者数据的到达。
4. A client connects (4) to the logging server;
一个客户端连接到服务
5. The Logging Acceptor is notified by the Initiation Dispatcher (5) of the new connection request;
当一个连接请求过来时,日志接收器被初始化分发器唤醒。
6. The Logging Acceptor accepts (6) the new connection;
日志接收器接受新的连接 。
7. The Logging Acceptor creates (7) a Logging Handler to service the new client;
日志接收器创建一个日志处理器来服务新的客户端。
8. Logging Handler registers (8) its socket handle with the Initiation Dispatcher and instructs the dispatcher to notify it when the socket becomes “ready for reading.”
日志处理器通过初始化分发器注册到处理他的socket 上去,并且指示分发器当socket 变成准备好的时候提醒他。

图B是后续其他客户端连接的处理过程:
1. The client sends (1) a logging record;
一个客户端发送一个日志。
2. The Initiation Dispatcher notifies (2) the associated Logging Handler when a client logging record is queued on its socket handle by OS;
当一个客户端的日志进入到处理器的队列, 初始化分发器通知相关联的日志处理器。
3. The record is received (3) in a non-blocking manner (steps 2 and 3 repeat until the logging record has been received completely);
日志接受通过非阻塞的方式通过重复步骤2和步骤3直到所有日志接受完毕。
4. The Logging Handler processes the logging record and writes (4) it to the standard output.
日志处理器处理日志,并且写到标准输出里边。
5. The Logging Handler returns (5) control to the Initiation Dispatcher’s event loop.
处理完毕返回到 Initiation Dispatcher时间循环。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Netty5.0 架构剖析和码解读 作者:李林锋 版权所有 email neu_lilinfeng@ © Netty5.0 架构剖析和码解读1 1. 概述2 1.1. JAVA 的IO演进2 1.1.1. 传统BIO通信的弊端2 1.1.2. Linux 的网络IO模型简介4 1.1.3. IO复用技术介绍7 1.1.4. JAVA的异步IO8 1.1.5. 业界主流的NIO框架介绍10 2.NIO入门10 2.1. NIO服务端10 2.2. NIO客户端13 3.Netty分析16 3.1. 服务端创建16 3.1.1. 服务端启动辅助类ServerBootstrap16 3.1.2. NioServerSocketChannel 的注册21 3.1.3. 新的客户端接入25 3.2. 客户端创建28 3.2.1. 客户端连接辅助类Bootstrap28 3.2.2. 服务端返回ACK应答,客户端连接成功32 3.3. 读操作33 3.3.1. 异步读取消息33 3.4. 写操作39 3.4.1. 异步消息发送39 3.4.2. Flush操作42 4.Netty架构50 4.1. 逻辑架构50 5. 附录51 5.1. 作者简介51 5.2. 使用声明51 1. 概述 1.1.JAVA 的IO演进 1.1.1. 传统BIO通信的弊端 在JDK 1.4推出JAVANIO1.0之前,基于JAVA 的所有Socket通信都采用 BIO 了同步阻塞模式( ),这种一请求一应答的通信模型简化了上层的应用开发, 但是在可靠性和性能方面存在巨大的弊端。所以,在很长一段时间,大型的应 C C++ 用服务器都采用 或者 开发。当并发访问量增大、响应时间延迟变大后, 采用JAVABIO作为服务端的软件只有通过硬件不断的扩容来满足访问量的激 增,它大大增加了企业的成本,随着集群的膨胀,系统的可维护性也面临巨大 的挑战,解决这个问题已经刻不容缓。 首先,我们通过下面这幅图来看下采用BIO 的服务端通信模型:采用BIO 通信模型的 1connect NewThread1 WebBrowse 2connect 2handle(Req) WebBrowse 3connect Acceptor NewThread2 WebBrowse WebBrowse 4connect NewThread3 3sendResponsetopeer NewThread4 图1.1.1-1 BIO通信模型图 服务端,通常由一个独立的Accepto 线程负责监听客户端的连接,接收到客户 端连接之后为客户端连接创建一个新的线程处理请求消息
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值