一，用户空间和内核空间

二，阻塞IO(Blocking IO)

三，非阻塞IO(NonBlocking IO)

四，IO多路复用(IO Multiplexing)

4.1 介绍

4.2 select

4.3 poll

4.4 epoll

select 模式存在的三个问题:

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

poll 模式的问题:

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

epoll 模式中如何解决这些问题的?

基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高，性能不会随监听的FD数量增多而下降
每个FD只需要执行一次epoll ctl添加到红黑树，以后每次epol_wait无需传递任何参数，无需重复拷贝FD到内核空间

4.5 事件通知机制

当 FD 有数据可读时，我们调用 epoll_wait 就可以得到通知。但是事件通知的模式有两种:

LevelTriggered:简称LT。当FD有数据可读时，会重复通知多次，直至数据处理完成。是Epoll的默认模式
EdgeTriggered:简称ET。当FD有数据可读时，只会被通知一次，不管数据是否处理完成。

举例：

假设一个客户端socket对应的FD已经注册到了epoll实例中
客户端socket发送了2kb的数据
服务端调用epoll_wait，得到通知说FD就绪
服务端从FD读取了1kb数据
回到步骤3(再次调用epoll_wait，形成循环)

4.6 Web服务流程（基于EPoll）

五，信号驱动IO(Signal Driven IO)

六，异步IO(Asynchronous IO)

七，Redis网络模型

7.1 Redis是单线程还是多线程

Redis 到底是单线程还是多线程?

如果仅仅聊Redis的核心业务部分(命令处理)，答案是单线程
如果是聊整个Redis，那么答案就是多线程

在 Redis 版本迭代过程中，在两个重要的时间节点上引入了多线程的支持

Redis v4.0:引入多线程异步处理一些耗时较长的任务，例如异步删除命令unlink
Redis v6.0:在核心网络模型中引入多线程，进一步提高对于多核CPU的利用率

为什么 Redis 要选择单线程

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

7.2 Redis单线程网络模型流程

Redis 通过 I0 多路复用来提高网络性能，并且支持各种不同的多路复用实现，并且将这些实现进行封装，提供了统一的高性能事件库 API 库 AE：

源码简化：

流程图：

源码解析：

Redis网络模型