一，用户空间和内核空间
二，阻塞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：
源码简化：
流程图：
源码解析：
7.3 Redis多线程网络模型流程
