Open JemmyH opened 3 years ago
在高性能的网络 I/O 设计中,有两个著名的模型: Reactor模型
和 Proactor模型
,前者用于 同步 I/O,后者用于 异步 I/O。有一点可以明确,不管是哪个模型,其目的都是提高服务端程序的并发能力。
对于支持多连接的服务器,一般情况下可以总结为 2种fd 和 3种事件: 2种fd:
listen fd
: 一般情况下只有一个,用来监听特定的端口,代表服务器程序;connect fd
:每当客户端和服务器建立连接,就会产生一个 connect fd
,此后客户端的所有操作如收发数据都是通过这个 connect fd
。3种事件:
listen fd
进行 Accept
监听客户端的连接,创建新的 connect fd
;connect fd
都有两个缓冲区 read buffer
和 write buffer
;connect fd
发来的数据,进行对应的逻辑处理后,将数据发送到对应的 write buffer
中。在这个模型中,有三种角色:
Reactor
:将 I/O事件
分配给对应的 handler
处理;Acceptor
:处理客户端的连接事件;Handler
:进行的具体的业务逻辑处理从上面的定义以及这里的角色我们可以有一个大概的轮廓:
根据 Reactor的数量 和 处理资源的线程数量,分为三类:
在 Reactor 中处理并分发事件,如果是连接事件就交给 Acceptor,如果是读写事件就交给对应的 Handler 进行业务处理。这三个角色其实是一个线程在工作,始终是一个线程在处理所有的事。
区别于第一种,这种模型主要将业务处理从 Reactor 的单一线程中脱离出来,换成了额外的线程池去处理。也就是说,Reactor 只处理连接事件和读写事件,业务处理交给了线程池,线程池可以充分利用多核机器的资源。
与第二种模型相比,将 Reactor 拆分成了 MainReactor 和 SubReactor,前者只处理连接事件,读写事件交给后者,业务逻辑依旧使用线程池来处理。
Reator 是一种事件处理模型,并发处理请求,然后对请求进行多路分解,并将它们同步分派给关联的请求处理程序。本 issue 旨在搞清楚此模型的运作方式、高效的原因 以及 有哪些对其进行的相关改进措施。