redis自学(15)IO多路复用

 

无论是阻塞IO还是非阻塞IO,用户应用在一阶段都需要调用recvfrom来获取数据,差别在于无数据时的处理方案:

  •  如果调用recvfrom时,恰好没有数据,阻塞IO会使进程阻塞,非阻塞IO使CPU空转,都不能充分发挥CPU的作用。
  •  如果调用recvfrom时,恰好有数据,则用户进程可以直接进入第二阶段,读取并处理数据。

比如 服务端处理客户端Socket请求时,在单线程情况下,只能依次处理每一个Socket,如果正在处理的Socket恰好未就绪(数据不可读或不可写),线程就会被阻塞,所有其他客户端socket都必须等待,性能自然会很差。

 

 

多线程确实是可以提高效率,但也不是绝对的,因为CPU在多个线程间的上下文切换开销也很大,如果线程过多,反而会降低效率。

 

用户进程如何知道内核中数据是否就绪呢?

文件描述符(Flie Descriptor:简称FD,是一个从0开始递增的无符号整数,用来关联Linux中的一个文件。在Linux中,一切皆文件,例如常规文件、视频、硬件设备等,当然也包括网路套接字(Socket)。

IO多路复用:是利用单个线程来同时监听多个FD,并在某个FD可读、可写时得到通知,从而避免无效的等待,充分利用CPU资源。

 

 

与阻塞IO区别在哪里呢?区别在IO多路复用调用的是select命令,它包含的是对多个FD的监听,一旦有一个或者多个FD就绪了,就立马返回,然后用户态再调用recvfrom,准确的调用就绪的FD,如果多个FD都没有就绪,也会阻塞等待,但是这种可能性很小,但凡等待过程中有一个FD就绪了,就立马进行下一步了。

监听FD的方式、通知的方式又有多种实现,常见的有:

  •  Select
  •  Poll
  •  Epoll

差异:

  •  selectpoll只会通知用户进程有FD就绪,但不确定具体是哪个FD,需要用户进程逐个遍历FD来确认
  •  epoll则会再通知用户进程FD就绪的同时,把已就绪的FD写入用户空间
posted @ 2024-03-11 15:35  蓝海的bug本  阅读(9)  评论(0编辑  收藏  举报