1.用户空间和内核空间

2.阻塞IO

3.非阻塞IO

 4.IO多路复用

select模式的三个问题：
能监听的FD最大不超过1024
每次select都需要把所有要监听的FD都拷贝到内核空间
每次都要遍历所有FD来判断就绪状态

poll模式的问题：
poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降

epoll模式中如何解决这些问题的？
1.基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高，性能不会随监听的FD数量增多而下降
2.每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epol_wait无需传递任何参数，无需重复拷贝FD到内核空间
3.内核会将就绪的FD直接拷贝到用户空间的指定位置，用户进程无需遍历所有FD就能知道就绪的FD是谁

1.select

过程：

存在的问题：
1.需要将整个fd_set从用户空间拷贝到内核空间，select结束还要再次拷贝回用户空间
2.select无法得知具体是哪个fd就绪，需要遍历整个fd_set
3.fd_set监听的fd数量不能超过1024 

2.poll（性能相比select无明显提升）

过程：

3.epoll

过程：

 4.例子：web服务流程

 5.redis为什么选择单线程？

Redis到底是单线程还是多线程？
• 如果仅仅聊Redis的核心业务部分（命令处理），答案是单线程
• 如果是聊整个Redis，那么答案就是多线程
在Redis版本迭代过程中，在两个重要的时间节点上引入了多线程的支持：
• Redis V4.0：引入多线程异步处理一些耗时较长的任务，例如异步删除命令unlink
• Redis V6.0：在核心网络模型中引入 多线程，进一步提高对于多核CPU的利用率

为什么Redis要选择单线程？
1.抛开持久化不谈，Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，因此多线程并不会带来巨大的性能提升。
2.多线程会导致过多的上下文切换，带来不必要的开销。
3.引入多线程会面临线程安全问题，必然要引入线程锁这样的安全手段，实现复杂度增高，而且性能也会大打折扣 。

6.redis的网络模型

 

 整体而言：就是IO多路复用+事件派发，在此过程中不断监听客户端和服务端的socket的事件（可读/可写），监听到事件后做派发给三个不同的处理器

服务端可读处理器：接受客户端socket，注册客户端fd到多路复用程序

客户端可读处理器：接受请求，把请求读到缓冲区，等待排队输出，同时触发写事件

客户端可写处理器：写事件触发，将内容写到客户端