【架构】从 Socket 的角度认识非阻塞模型

文章目录

- 前言
- [1. 阻塞模型](#1. 阻塞模型)
- [2. 非阻塞模型](#2. 非阻塞模型)
- - [2.1 Reactor 模型优势](#2.1 Reactor 模型优势)
  - [2.2 Reactor 模型劣势](#2.2 Reactor 模型劣势)
- 后记

前言

近期看了很多中间件的文章，RocketMQ，Dubbo 这些中间件内部的rpc通信都用的是非阻塞的模型。(Netty)，这里从 Socket 的角度总结一下。

1. 阻塞模型

一个线程处理socket的连接和读写，如果使用的是阻塞IO，程序会在读取前后傻傻的呆着。比如：

文件上传
服务端阻塞读，没数据就等着。由于存在着TCP的拥塞控制，会产生空闲时间
文件下载
服务端阻塞写，网卡有其他数据排队就等着。

2. 非阻塞模型

以 Netty 的主从 Reactor 模型为例子，处理流程大致如下

boss 线程 （如图一个线程，4个事件在循环）
- 单线程
- 入队一个新的 socket 连接请求
- 事件循环捞出可连接的 socket
- 连接 socket，当前事件循环使命结束，后续交由 worker线程处理
worker 线程池 （如图2个线程，每个线程各有2个事件在循环）
- 默认是 CPU * 2 的线程数量
- 承接来自 boss 线程的可读写 socket
- 事件循环捞出可读/可写状态的 socket
- 读/写 socket
- 完成读写后，释放 socket，worker 与 boss 中的 socket 引用后续同时可以被虚拟机回收。

2.1 Reactor 模型优势

同样的请求数，线程数减少了，不需要同步或文本切换带来的低开销。
默认基于 Tcp 而不是 Http，对于开发RPC协议是很轻量的选择。
方便模块化，能写出形如以下的声明式代码。

java 复制代码

// 主从 Reactor 模式
ServerBootstrap bootstrap = new ServerBootstrap();
        bootstrap.group(new NioEventLoopGroup(), new NioEventLoopGroup())
            .channel(NioServerSocketChannel.class)
            .childHandler(new ChannelInitializerImpl());

// worker 中的流水线定义
ch.pipeline().addLast(
            new HttpServerCodec(),
            new HttpObjectAggregator(65536),
            new WebSocketServerProtocolHandler("/websocket"),
            new TextFrameHandler(),
            new BinaryFrameHandler(),
            new ContinuationFrameHandler());

2.2 Reactor 模型劣势

编程模型复杂。
业务开发应用场景少。

后记

非阻塞模型可以将 Socket 的连接和读写过程拆开，读写时不阻塞（数据准备好了再操作）。优化了IO等待时间。当然更深层次的原因是使用了 Linux 的 epoll 指令，该指令能让操作系统做到及时发送 "数据准备就绪" 的通知，可以让 Socket 立马到就绪状态，原本的IO等待时间就可以空出来给操作系统做其他事情。