适合前端做项目的网站,网站开发子账号,深圳网站建设 卓,推广策略都有哪些文章目录 epollselect和poll的优缺点epoll的原理以及优势epoll 好的网络服务器设计Reactor模型图解Reactor muduo库的Multiple Reactors模型 epoll
select和poll的优缺点
1、单个进程能够监视的文件描述符的数量存在最大限制#xff0c;通常是1024#xff0c;当然可以更改数… 文章目录 epollselect和poll的优缺点epoll的原理以及优势epoll 好的网络服务器设计Reactor模型图解Reactor muduo库的Multiple Reactors模型 epoll
select和poll的优缺点
1、单个进程能够监视的文件描述符的数量存在最大限制通常是1024当然可以更改数量但由于 select采用轮询的方式扫描文件描述符文件描述符数量越多性能越差(在linux内核头文件中有 这样的定义#define __FD_SETSIZE 1024
2、内核 / 用户空间内存拷贝问题select需要复制大量的句柄数据结构产生巨大的开销
3、select返回的是含有整个句柄的数组应用程序需要遍历整个数组才能发现哪些句柄发生了事件
4、select的触发方式是水平触发应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作 那么之后每次select调用还是会将这些文件描述符通知进程
相比select模型poll使用链表保存文件描述符因此没有了监视文件数量的限制但其他三个缺点依然存在。
以select模型为例假设我们的服务器需要支持100万的并发连接则在__FD_SETSIZE 为1024的情况 下则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外 从内核/用户空间大量的句柄结构内存拷贝、数组轮询等是系统难以承受的。因此基于select模型的 服务器程序要达到100万级别的并发访问是一个很难完成的任务。
epoll的原理以及优势 epoll的实现机制与select/poll机制完全不同它们的缺点在epoll上不复存在。 设想一下如下场景有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻通常只有 几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发
在select/poll时代服务器进程每次都把这100万个连接告诉操作系统从用户态复制句柄数据结构到 内核态让操作系统内核去查询这些套接字上是否有事件发生轮询完成后再将句柄数据复制到用 户态让服务器应用程序轮询处理已发生的网络事件这一过程资源消耗较大因此select/poll一般 只能处理几千的并发连接。epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统文件系统一 般用什么数据结构实现B树磁盘IO消耗低效率很高。把原先的select/poll调用分成以下3个部分
调用epoll_create()建立一个epoll对象在epoll文件系统中为这个句柄对象分配资源调用epoll_ctl向epoll对象中添加这100万个连接的套接字调用epoll_wait收集发生的事件的fd资源
如此一来要实现上面说是的场景只需要在进程启动时建立一个epoll对象然后在需要的时候向这 个epoll对象中添加或者删除事件。同时epoll_wait的效率也非常高因为调用epoll_wait时并没有 向操作系统复制这100万个连接的句柄数据内核也不需要去遍历全部的连接。
//epoll_create在内核上创建的eventpoll结构如下
struct eventpoll{.... /*红黑树的根节点这颗树中存储着所有添加到epoll中的需要监控的事件*/ struct rb_root rbr; /*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/ struct list_head rdlist; ....
};epoll
epoll重点掌握LT模式和ET模式。
关于这一节可以读以下两篇博客 IO多路转接复用之epoll epoll边沿模式的非阻塞方法
好的网络服务器设计 陈硕老师的原话 在这个多核时代服务端网络编程如何选择线程模型呢 赞同libev作者的观点one loop per thread is usually a good model这样多线程服务端编程的问题就转换为如何设计一个高效且易于使 用的event loop然后每个线程run一个event loop就行了当然线程间的同步、互斥少不了还有其 它的耗时事件需要起另外的线程来做。 event loop 是 non-blocking 网络编程的核心在现实生活中non-blocking 几乎总是和 IOmultiplexing 一起使用原因有两点 没有人真的会用轮询 (busy-pooling) 来检查某个 non-blocking IO 操作是否完成这样太浪费 CPU资源了。IO-multiplex 一般不能和 blocking IO 用在一起因为 blocking IO 中 read()/write()/accept()/connect() 都有可能阻塞当前线程这样线程就没办法处理其他 socket 上的 IO 事件了。 所以当我们提到 non-blocking 的时候实际上指的是 non-blocking IO-multiplexing单用其 中任何一个都没有办法很好的实现功能。 更强大的网络服务器Nginx! 采用的是epoll fork 而不是epollpthread 用多个进程程来监听新链接不想muduo只有一个线程来监听网络连接 强大的nginx服务器采用了epollfork模型作为网络模块的架构设计实现了简单好用的负载算法使 各个fork网络进程不会忙的越忙、闲的越闲并且通过引入一把乐观锁解决了该模型导致的服务器惊群 现象功能十分强大。
Reactor模型
Reactor模型是一个设计一个高性能网络服务器的常用模型。 The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers. 反应堆设计模式是一种事件处理模式用于处理由一个或多个输入并发传递给服务处理程序的服务请求。然后服务处理程序对传入的请求进行多路复用并将它们同步地分派给相关的请求处理程序。 重要组件Event事件、Reactor反应堆、Demultiplex IO多路复用事件分发器、Evanthandler事件处理器 之后我们主要关注这四个组件的通信即可。
图解Reactor 交互流程
首先会把事件注册到反应堆上所谓的注册指的是应用程序对该事件比较感兴趣我们请求反应堆帮我来监听我所感兴趣的事件并且在事件发生的时候调用我预置的回调函数Handler反应堆可以理解为存储了一个Event事件以及事件处理的集合我们的事件处理可以添加很多的选项比如事件响应、事件处理等等。每一个Event都对应一个Handler所以的反应堆就维护了这样一个集合。然后reactor会调用epoll_ctl来设置相关的方法来处理sockfd这个过程是借助Demultiplex实现。我们这里的Demultiplex用来处理epoll_ctl的相关处理然后Reactor自己启动反应堆反应堆的后端就能驱动事件分发器Demultiplex(其实就是开启epoll_wait)的使用整个服务器呈现出阻塞的状态来等待新用户的链接或者是已连接用户的读写事件epoll_wait监听到了新事件产生Demultiplex会把事件给反应堆返回。 为什么Demultiplex会返回给Reactor呢因为事件Event发生后我们需要调用对应的事件处理器Handler这是我们注册在Reactor中的 最后对于发生事件的Event我们就通过一个Map表来找到该事件Event对应的那个EventHandler最后处理该任务。
muduo库的Multiple Reactors模型 在muduo网络库中Reactor中已经集成了Demultiplex IO多路复用事件分发器组件图片来源见水印 在 muduo 库中许多 client 在 MainReactor 中得到了连接请求的响应并与 WebServer 建⽴具体的连接。然后通过⼀个叫 Acceptor 的模块将具体的连接分配给到⼀些叫做 SubReactor 的 模块在 SubReactor 中对具体的连接进⾏读、编码、计算、解码和写操作即对 client 请求的响应。
所以改图有一点不准确Reactor其实就是存储了事件以及事件处理器仅此而已所以上图应该画成事件份发器。
