<font color="#0076b3">Reactor模型基于异步通知模式, 即有事情发生了, 我就通知你去处理</font>
Reactor
负责消息监听及事件响应，将事件分发给绑定了该事件的Handler处理<br>
假如是<font color="#c41230">连接事件</font>, 则交给<font color="#c41230">acceptor</font>处理
假如是<font color="#c41230">读写事件</font>, 则交给<font color="#c41230">handler</font>处理
Acceptor
<font color="#c41230">Handler的一种，绑定了connect事件.</font><br>注册channel到Reactor的selector中, 并创建对应的handlerPipe<br>
Handler
<font color="#c41230">事件处理器，绑定了某类事件.</font><br>完成channel的消息读取, 完成业务逻辑, 完成消息的发送<br>
单Reactor单线程模型
<font color="#c41230">1个主线程</font>
<font color="#c41230">Reactor和Handlers在同一个线程内</font>
1个Reactor
负责消息的监听, 及消息处理的分发<br>dispatch<br>
N个Handler
负责事件的响应处理<br>accept、read、decode、process、encode、send<br>
缺点
不能利用多核CPU
高并发时性能上无法支撑
一旦reactor线程意外跑飞或者进入死循环，会导致整个系统通信模块不可用
应用: redis
单Reactor多线程模型
<font color="#c41230">1个主线程+1个worker线程池</font>
1个Reactor<font color="#c41230">(主线程内)</font>
负责消息的监听, 及消息处理的分发<br>dispatch<br>
N个Handler<font color="#c41230">(主线程内)</font>
负责响应事件,不做具体的业务处理<br>read+send
worker线程池
具体的业务处理<br>decode+compute+encode
特点
1. 相对于单reactor单线程, 将具体的业务处理交给worker线程池处理, 提高了cpu的利用率
2. 目前的问题是, 在handler读取时仍会阻塞线程
主从Reactor多线程模型
Nginx, Netty, Memcached 都是应用该模式
<font color="#c41230">MainReactor线程池+SubReactor线程池+worker线程池</font>
MainReactor
监听连接事件,收到事件后,通过Acceptor处理连接事件<br>accept
SubReactor
连接事件处理完后, MainReactor将连接移交给SubReactor监听<br>接下来的各种事件处理由SubReactor去完成<br>read+send
worker
具体的业务处理<br>decode+compute+encode<br>
特点
<font color="#c41230">1. MainReactor只负责连接事件的处理+移交</font>
2. SubReactor负责事件的读写响应及消息处理的分发
3. worker线程负责具体的业务处理
优点
响应快,不必为单个同步事件所阻塞,虽然Reactor本身依然是同步的
可以最大程度的避免复杂的多线程的同步问题,并且避免了多线程/进程的切换开销<br>
扩展性好,可以方便的通过增加Reactor实例个数来充分利用CPU资源<br>
复用性好,<font color="#c41230">Reactor模型本身与处理逻辑无关</font>,具有很高的复用性<br>
小结
1. 单Reactor单线程,前台接待员和服务员是同一个人,全程为顾客服务
2. 单Reactor多线程,1个前台接待员,多个服务员,接待员只负责接待
3. 主从Reactor多线程,多个前台接待员,多个服务生
