0、Redis网络IO模型：
Redis 是单线程，主要是指 Redis 的网络 IO（Redis6.0以前）和键值对读写是由一个线程来完成的。持久化、异步删除、集群数据同步等，则是由额外的线程执行的。这样避免了多线程编程模式面临的共享资源的并发访问控制问题。
- 单线程服务器模型，面临的最大的问题就是，一个线程如何处理多个客户端请求？解决这种问题的办法就是「IO 多路复用」。它本质上是应用层不用维护多个客户端的连接状态，而是把它们「托管」给了操作系统，操作系统维护这些连接的状态变化，之后应用层只管问操作系统，哪些 socket 有数据可读/可写就好了，大大简化了应用层的复杂度
- IO 多路复用机制要想高效使用，一般还需要把 socket 设置成「非阻塞」模式，即 socket 没有数据可读/可写时，应用层去 read/write socket 也不会阻塞住（内核会返回指定错误，应用层可继续重试），这样应用层就可以去处理其它业务逻辑，不会阻塞影响性能
- 为什么 Redis 要使用「单线程」处理客户端请求？本质上是因为，Redis 操作的是内存，操作内存数据是极快的，所以 Redis 的瓶颈不在 CPU，而在内存和网络IO上，优化的重点就在网络 IO 上，高效的 IO 多路复用机制，正好可以满足这种需求，模型简单，性能也极高
- 但成也萧何败也萧何，因为 Redis 处理请求是「单线程」，所以如果有任意请求在 Server 端发生耗时（例如操作 bigkey，或一次请求数据过多），就会导致后面的请求发生「排队」，业务端就会感知到延迟增大，性能下降
- 基于此，Redis 又做了很多优化：一些耗时的操作，不再放在主线程处理，而是丢到后台线程慢慢执行。例如，异步关闭 fd，异步释放内存、后台 AOF 刷盘这些操作。所以 Redis Server 其实是「多线程」的，只不过最核心的处理请求逻辑是单线程的，这点一定要区分开。
1、io模型 有哪几种？
阻塞io/非阻塞io/多路复用io/异步io/信号驱动io
2、io多路复用 的概念：
一个线程处理多个io流 → select/epoll；其中Redis网络框架调用epoll机制，让内核去监听这些套接字。
3、io多路复用 起到的作用：
在网络io操作中能处理大量的客户端请求，实现高吞吐率。
4、io多路复用 是在什么层面实现的？
操作系统层面
5、io多路复用 的原理：
Linux中的 IO多路复用 机制是指一个线程处理多个IO流，就是我们经常听到的 select/epoll 机制。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个“监听套接字”和“已连接套接字”。内核会一直监听这些套接字上的“连接请求”或“数据请求”。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。此时，Redis 线程不会阻塞在某一个特定的监听或已连接套接字上（即不会阻塞在某一特定的客户端请求处理上），而是可以返回正常处理其他客户端请求操作，从而提升并发性。
6、epoll 基于事件的回调机制：
为了在请求到达时能通知到 Redis 线程，select/epoll 提供了基于事件的回调机制，即针对不同事件的发生，调用相应的处理函数。
select/epoll 一旦监测到 FD 上有请求到达时，就会触发相应的事件，其实就是Redis会在select/epoll 机制上提前去注册Redis自己提供的回调函数。这些事件会被放进一个事件队列，Redis 单线程对该事件队列不断进行处理。这样一来，Redis 无需一直轮询是否有请求实际发生，这就可以避免造成 CPU 资源浪费。同时，Redis 在对事件队列中的事件进行处理时，会调用相应的处理函数，这就实现了基于事件的回调。因为 Redis 一直在对事件队列进行处理，所以能及时响应客户端请求，提升 Redis 的响应性能。
举例：这两个请求分别对应 Accept 事件和 Read 事件，Redis 分别对这两个事件注册 accept 和 get 回调函数。当 Linux 内核监听到有连接请求或读数据请求时，就会触发 Accept 事件和 Read 事件，此时，内核就会回调 Redis 相应的 accept 和 get 函数进行处理。
另外Redis在6.0推出了多线程，可以在高并发场景下利用CPU多核多线程读写客户端数据，进一步提升server性能。当然，只是针对客户端的读写是并行的，每个命令的真正操作依旧是单线程的。
