对 Reactor 始终隔了一层纱？

发表于 2年以前 | 总阅读数：409 次

在深入 Netty 的 Reactor 实现之前，我想先聊聊到底什么是 Reactor ？

这个问题其实困扰了我很久，之前我在网上找了好多文章，但看下来总感觉隔了一层纱。

我还去找了 Reactor 的论文，可能由于个人水平太差，看得我更迷糊了...一堆概念看的我头昏眼花。

最后我去看了 Redis 和 Netty 的源码，因为它们都实现了 Reactor，看下来感觉 Reactor 好像没看起来的那么复杂，并且实现和理论还是有点差别的。

所以，接下来我会基于看过的两个开源项目的 Reactor 实现和自己的 YY 下，来谈谈对 Reactor 的理解，如有错误还请指正。

对 Reactor 的理解

Reactor 是个啥呢？其实它算是一个编程模式或者说一个架构模式，常用在服务端网络通信相关的模块。

Reactor 直译到中文是反应堆，虽然直译不贴切，但确实跟“反应”有关。

反应啥呢？对触发的事件进行反应。

在大学的时候，我相信很多人都做过图书管理系统等类似的大作业，这种都是基于 Java GUI 做的，当然具体如何实现的不重要，重要的是你完成之后的成品是不是点击一个按钮就会弹出一个对应的弹框？

点击按钮就会弹框，不同的按钮弹不同的框，这就是反应。

咱们计算机不就讲究抽象嘛，所以把这上面说的这些抽象一下，就是针对不同的事件需要有不同的处理逻辑（方法调用）。

到这，我们得到了两个概念：事件（点击按钮）和处理逻辑（弹对应的框）。

再回到弹框这个场景，思考下，到底是谁在监听着按钮被点击的动作来弹出不同的框呢？

这里，我们很容易想到两种情况：

一个按钮派一个线程在守着，只要按钮被点击了，这个线程就执行弹框
一个线程轮询所有按钮的情况，死循环查看只要有一个按钮被点击了，就找出按钮绑定的框，然后弹

如果按钮很少，其实多派几个线程守着影响不大，假设有一千个、一万个按钮呢？这种场景下第二种实现更优，毕竟按钮也不是一直会被点击着，对吧。

我们把“人”、“点击按钮”、“弹框”对应到网络编程中，就是线程、事件、处理。

第一种情况翻译过来就是一个线程接待一个连接，每当连接上有事件产生，则线程会对应事件作出响应。

这对应着很早之前的网络编程模型，那时候网上没那么多用户，并且也就只有阻塞 I/O，如果连接没有反应，那么线程就得阻塞等待着 I/O 事件的发生。

第二种情况翻译过来就是，由一个线程接待多个连接，不论哪个连接上有事件产生，这个线程都会根据事件找到对应的处理逻辑来作出响应。

这就是对应现在流行的基于非阻塞 I/O 的 I/O 多路复用，这种场景就适合海量用户的情况，服务端可用很少线程来处理数量庞大的连接，就像我上面说的，毕竟连接（按钮）也不是一直会有请求过来（被点击）。

至于我前头提到的事件，基础的 I/O 上的事件也就这三种：连接事件、读事件、写事件。

现在回到网络 I/O 上，我们再来看 Reactor：也就是有一个 selector（select/poll/epoll）线程，它管理着很多连接，只要某个连接上有事件产生，就会唤醒 selector 线程，这个线程就会根据发生的事件类型做不同的处理。

这就是 Reactor，对应的线程也叫 Reactor 线程（就靠它起反应啦）。

那没 Reactor 的场景是怎样的？

就是上面提的第一种情况，一个线程接待一条连接。不像第二种情况这样，由一个线程来接待许多连接，由一个“负责人”来接待多个客户，这种什么事都找一个人，是不是感受起来那个人就像一个 Reactor？

能一对多的根据不同请求做出不同响应实现，是我个人认为的 Reactor 核心。至于事件、调度器、Acceptor等玩意，我觉得是为了写论文或者文章必须要搞的一些概念，反正理解了之后，也就这么回事儿，因为要从流程上走通必须得有这么些个东西。

就像我们所知的 SpringMVC，要想一个请求能找到对应的 Controller，那不就得有个统一入口判断路由嘛，所以必须要有这么个东西，不然请求到不了 Controller 了啊，那这个玩意叫啥？不就是 DispatcherServlet 吗，中文名不就是前置控制器吗。

所以，不是说 SpringMVC 需要有 DispatcherServlet 这么个玩意，而是 SpringMVC 需要有个统一入口判断路由，所以就弄了个实现类，这个实现类呢就叫 DispatcherServlet。

你懂我的意思吧。

同样看 Reactor 也是一样的，不是说 Reactor 需要有个叫 Demultiplexer、 Dispatcher、Handle、Event Handler 这么些个玩意才叫 Reactor 。

而是在网络 I/O 中基于非阻塞 I/O ，且需要少量的线程接待大量的连接，这样一场景下，就必须要个玩意作为一个监听者，监听底层这么多连接是否有请求，然后根据请求的类型（抽象的事件），指派调用不同的处理逻辑，才对应衍生出上面这么些个名词。

在具体的实现上， Demultiplexer 和 Dispatcher 当然可以是同一个线程，同在一个死循环里面，这都是 ok 的，不要看着名词就理解着，代码里必须分这么两个玩意，不是的哈。

基于上面的理解，然后再看看来自 Reactor 论文的这张图把，是不是好理解了。

最后再说个官方点的回答吧：

Reactor 是服务端在网络编程时的一个编程模式，主要由一个基于 Selector （底层是 select/poll/epoll）的死循环线程，也称为 Reactor 线程。将 I/O 操作抽象成不同的事件，每个事件都配置对应的回调函数，由 Selector 监听连接上事件的发生，再进行分发调用相应的回调函数进行事件的处理。