zoukankan      html  css  js  c++  java
  • 由select引发的思考

    一、前言

      网络编程里一个经典的问题,select,poll和epoll的区别?这个问题刚学习编程时就接触了,当时看了材料很不明白,许多概念和思想没有体会,现在在这个阶段,再重新回头看这个问题,有一种豁然开朗的感觉,

    把目前我所能理解到的记录下来。

      参考资料:https://www.cnblogs.com/zingp/p/6863170.html

           http://blog.csdn.net/a837199685/article/details/45954349

           https://www.zhihu.com/question/32163005

           http://shmilyaw-hotmail-com.iteye.com/blog/1896683

           http://www.cnblogs.com/my_life/articles/3968782.html

           https://www.cnblogs.com/Anker/p/3265058.html

    二、从操作系统开始谈起

      有几个以后一直谈到的概念,有必要先了解,以前就是这个步骤没做,学习的时候一脸懵逼。

      1. 用户空间和内核空间

        目前操作系统寻址模式为虚拟寻址,即处理器产生虚拟地址,之后翻译成物理地址,总线到物理地址处理,处理器拿到处理后的数据

        操作系统 的核心为内核,可以访问受保护的内存空间,可以访问底层硬件设施,可以做任何事情。所以为了系统的稳定,讲道理内核应该被保护起来。

        所以虚拟空间被分为内核空间和用户空间。内核空间在最高的1G中,用户空间在剩下的内存中。

        多数我们所用的进程在用户空间处理,把请求发给内核,在内核空间中操作硬件。

      

      2. 进程上下文切换(进程切换)

        挂起当前进程,恢复某个进程,大家都知道这是个开销大的过程,那具体有哪些步骤呢?

        首先,保存当前进程一些必要信息用以日后恢复,如描绘地址空间的页表,进程表,文件表等等。

        然后切换页全局目录,安装一个新的地址空间

        最后回复目标进程的上下文

      3. 文件描述符(fd)

        计算机的一个术语,指向文件对象的一个抽象表示。形式上是一个非负整数的索引值,指向文件表中的文件

        当程序打开或创建一个文件时,内核向进程返回一个文件描述符,代表该文件。

        通过操作文件描述符,我们实现真实操作文件的目的

      4.  进程阻塞(process block)

        当某个进程等待一个执行结果时,自身阻塞(不干事),直到得到结果,再继续往下,

        重点是:这个是进程自身行为,且阻塞时不占用cpu资源(cpu也不干事),

        所以I/O请求最拉低性能,俗话说占着茅坑不拉屎,在计算机里也是存在的,所以人们设计了多线程,多进程等方案来解决这个问题。

      

      5.  I/O过程

        一般有两种模式,直接 I/O,缓存 I/O(默认),

        缓存 I/O:

          进程发起系统调用(通知系统我要读写了!)

          写: 进程(数据) -------》 进程缓冲池   ------------》 内核缓冲池 ----------》存储设备

          读: 存储设备(数据)---------》内核缓冲池 ----------》进程缓冲池 ---------》进程

        直接 I/O(进程缓存池消失了!):      

          进程发起系统调用(通知系统我要读写了!)

          写: 进程(数据)    ------------》 内核缓冲池 ----------》存储设备

          读: 存储设备(数据)---------》内核缓冲池  ---------》进程

        以上每个步骤之间都是有可能进程会有阻塞(block)发生,根据不同位置的阻塞,就产生了多种网络模式,以适应于不同场景。

         

    三、 I/O模式(以读为例)

       1.  block I/O 

        过程 :  

          进程发起系统调用(通知系统我要读写了!)

          读: 存储设备(数据)---------》内核缓冲池  ---------》进程------------》内核通知进程ok,进程解除阻塞

                     进程阻塞                   进程阻塞

        解释:

          进程一直等文件准备好,再继续下一步。

        应用场景:

          以上原理是一个用户连接的情况,很容易理解。

          当一个服务器对接多个客户端的时候:

          初级方案:开多进程(大数据或长时间任务、开销大,更安全)或多线程(很多连接,开销低,数据放一起不太安全)为每一个客户端建立一个连接来处理。

          不足:高并发的情况就体现出开销大,性能低。一个是多线程切换,上下文切换的性能开销,另一个是多线程数量大,会占据大量系统资源

          优化方案:采用线程池(减少创建和销毁线程的频率)或连接池(维持连接的缓存池,尽量重用已有的连接),降低系统开销

          不足:降低开销还是有限度的,在这个时代,高并发大,很容易到达瓶颈。

       

       2. non-block I/O   

        过程 :  

          发起系统调用(通知系统我要读写了!)

          读: 存储设备(数据)-------------》内核缓冲池  -----------》进程-------------》内核通知进程ok,进程解除阻塞

                     非阻塞                              阻塞

        解释:

          在内核准备数据阶段,立即返回一个error给进程,

          因此进程知道内核还没准备好,

          所以进程再问内核,内核再回error,直到内核准备好,被询问时返回准备好的信号,进程再接触阻塞,

        应用场景:

          连接量小,没差别,

          当连接数大的时候,这个模式理论上可以用一个线程实现多个连接:

          由于非阻塞,这个线程可以循环去询问所有连接目标有没有准备好,内核都是立马回复,error往下,准备好就交给进程,所以不会浪费时间,

          但是,(凡事都有但是),这个简单的实现方案,效率还是很低的,毕竟从内核空间到用户空间还是block的,而且会极大推高cpu占用率。

          特别是当响应事件(读取或者其他)庞大的时候,执行速度就会很缓慢。

          下面的select等就是基于此想法的发展。

       3. I/O multiplexing

        目标:低开销,高效率得处理高并发请求

        方案:select 、poll、epoll 三种实现方案

        本质:用 select、poll、epoll 去监听所有 socket对象,当socket对象发生变化时,通知用户进程处理。

        特征:

           select(最早出现):多平台支持

                    通过轮询,效率较低

                    处理连接数量有限制,默认1024个,

                    大量用户态和内核态fd的拷贝,性能低,

                    返回的是所有句柄列表,没有告诉是哪一个发生变化,用户进程还得再次遍历。

           poll(略微改进):改进了数量连接限制,做到了数量无限制

           epoll(改进所有缺点):当socket变化时,通知进程哪一个完成了,

                      数量无限制(为系统最大打开文件数量)

                      fd句柄只拷贝一次,性能高

        性能对比:

          

          横坐标是连接数,Dead Connections 是软件命名的,纵坐标是此时处理连接数

          可以看出 epoll 性能比较稳定,而且性能较优。

        仔细过程讨论:

            这里只讨论大致原理,具体实现不同语言有不同的差别。(不是因为我没做过,不是的)

            首先。在多路复用模型中,对于每一个 socket,一般都设置成为 non-blocking,但是,整个用户的 process 其实是一直被 block 的

            即用户进程被select、poll阻塞,但是select、poll是非阻塞的,他们不断轮询、挂起来完成工作。

            select:

              1. 从用户态拷贝 fd_set 至内核空间(告诉内核要监听的socket)

              2..注册回调函数pollwait(将进程挂到等待队列中,当socket准备好后(执行mask状态码判断),再唤醒进程)

              3. 内核遍历fd,调用每一个的poll方法(本质上是pollwait回调函数,返回值socket的mask状态掩码,即现在准备好了没,给fd_set赋值)

              4. 当无可读写mask码(没有任何准备好的),select睡眠,等睡眠时间到,再次醒来轮询fd-set

              5. 有值时返回fd_set(已经赋值完,例如可以读的value为1)、将其拷贝至用户空间

              6. 用户进程循环fd_set,

            分析:

              每次循环都要执行上面流程,

              一次循环两次拷贝fi_set,即每次监听都重新告诉内核要监听的事件,在用户量很大的时候是一个很大的开销

              返回所有的fd_set,却没有告诉进程哪一个是完成的,进程还得循环判断,用户量很大(十万,百万)的时候,性能太低

              因此,select只支持1024个连接。

              这也解释了上图中为什么连接量越大,性能越低的现象,许多时间用来处理无活跃的连接、循环判断中,在高并发低活跃的场景中尤为如此。

            poll:

              将fd_set结构改为pollfd结构,可以不限数量,但是其他问题咩有解决。

            epoll:

              改进:

                fd只拷贝一次(开始就告诉内核所有注册事件,监听对象)。

                只返回包含所有变化的fd的链表。

                连接无限制

              epoll提供三个函数

              epoll_create(句柄),开始是有size参数,说明fd数量,现在内核动态分配,

              epoll_ctl(注册事件类型),注册监听事件

              epoll_wait(等待事件发生),捕捉fd信号,

        三者区别小结:

          select、poll 孪生兄弟,有许多缺点,优点不多,应用场景也不多。是时代的产物

          epoll  是进阶版,但是只有Linux有,

          具体情况具体分析。

      

      4. 异步io

        解释:进程完全不阻塞,请求发完就去做其他事,等数据全部准备好,内核发消息给进程,进程接着处理,

        实现:听说很复杂,没研究。

    四、总结和挖坑

      研究了一些操作系统的概念,研究了I/O模式,着重研究了select、poll、epoll 的区别,

      有时间 具体实现和操作,实践出真知,许多细节可能还有谬误,待以后水平上升,再来修改。

              

              

              

           

  • 相关阅读:
    Mycat的server.xml配置
    Docker构建Mycat(单节点)
    Mycat相关概念解读
    Mycat简介及适用场景
    SpringBoot整合WebService
    SpringBoot事务简单操作及手动回滚
    对事务及其注解@Transactional的解读
    git将某分支的某次提交合并到另一分支
    SpringBoot快速支持国际化i18n
    SpringBoot多数据源自动切换
  • 原文地址:https://www.cnblogs.com/xinghuaikang/p/8502983.html
Copyright © 2011-2022 走看看