redis线程模型：

网络模块+命令处理
redis的性能：
一个取决于物理内存，另一个是对于socket请求的处理速度。

4.0以前

单线程模式

请求流程：对于一个请求，线程会根据操作产生相应的事件（读，写事件），此时我们的程序对事件进行监听，监听到程序，交给文件事件分派器选择不同的处理器去处理，最后返回给socket

单线程能保证高性能

• 内存存储：Redis使用内存作为数据存储介质，避免了磁盘I/O操作的瓶颈，这使得数据访问速度非常快。
• 单线程模型：Redis通过单线程模型简化了内部逻辑，避免了多线程中频繁的上下文切换开销。
• 事件驱动机制：由“事件”驱动运行的，事件状态对象、事件源、事件监听器。

产生问题：

• 在当时redis单线程模型的处理速度很快，完全可以应对上亿的请求，但是redis在处理del bigkey时出现处理时间过长问题，这导致出现redis出现阻塞情况，性能变差，所以在4.0版本redis进行了部分改动。

4.0版本（伪多线程模式）

主线程（1个）+后台线程（3个）

解决策略：

后台线程（3）个：
close_file:关闭AOF,RDB过程中产生的大文件
aof_fsync：将追加至AOF的文件数据刷盘
lazy_free：惰性释放大对象（bigkey）
此时redis的思想是将专门的事交给专业的线程去做，对于耗时较长的操作都分别开启了对应的线程去进行处理。

惰性删除（lazy_free)：只有当我们访问到该key时发现过期，才会对他进行删除
AOF：redis持久化存储，将所有的写操作存储到AOF文件当中，可以在关闭服务器之后还原之前的状态
RDB：对任意时刻的redis中所有的数据生成快照保存的硬盘中，可手动和自动，适合灾难性恢复。

6.0版本

在4.0版本处理了命令操作的问题，但是网络传输的发展，业务的扩展，请求数不断增长，但是对于redis来说，处理socket请求的线程只有一个（aeMain），想要提升处理速度，就需要开启多线程模式了。
多线程+后台线程
开启语句：io-thread-do-read yes

实现：采用epoll 机制实现 IO 多路复用

当客户端有数据发送至服务端时，Select 会监听到可读事件，数据读取完毕后提交到业务线程池中并发处理。
一般的请求中，耗时最长的一般是业务处理，所以用一个线程池（worker 线程池）来处理业务操作，在性能上的提升也是非常可观的。

在Reactor多线程模型中，业务逻辑通常指的是接受和处理客户端请求之后的操作，比如数据的查询、加工以及持久化等。

接收到socket请求后，我们采用eaMain()主线程对已经就绪的事件进行轮询，对于这一步，采用的是epoll机制，记录 「要监听的文件描述符」 和 「已经就绪的文件描述符」，「已就绪的文件描述符」是由内核主动添加至就绪文件描述符集合中，我们从用户态调用 epoll_wait 就直接查询该集合是否有就绪 I/O 事件，这样下来，就减少了全遍历所有文件描述符的操作。

网络I/O多线程处理：Redis 6.0版本中，网络数据的读写这类耗时操作采用多线程执行，这样可以充分利用服务器的多核CPU资源。
命令执行仍为单线程：尽管网络I/O是多线程处理的，但Redis中执行用户命令的核心环节仍然是单线程的，这样避免了多线程环境下可能出现的数据竞态问题。

对于已经就绪的事件，通过io多路复用程序将任务分发给不同的事件处理器进行处理，如果是读写请求，就将读写的响应通过 socket 响应给客户端。

总结：6.0版本，redis采用的是多线程+后台线程的方式，对于socket请求，我们采用eaMain主线程轮询socket操作产生的事件，事件产生被io多路复用处理后交给分别交给不同线程进行后续操作，比如查询等，除此之外还开启线程对处理速度较慢的事件单独开启后台线程。

使用：

• 通常情况下，redis多线程是关闭的，4核以上推荐开启
• 4核——2,3线程
• 8核——6线程
• 线程数不是越多越好，通常建议线程数小于核数