Redis 6.0 之前为什么不使用多线程？
官方答复：
- 使用 Redis 时，几乎不存在 CPU 成为瓶颈的情况， Redis 主要受限于内存和网络。
- 在一个普通的 Linux 系统上，Redis 通过使用pipelining 每秒可以处理 100 万个请求，所以如果应用程序主要使用 O(N) 或O(log(N)) 的命令，它几乎不会占用太多 CPU。
- 使用了单线程后，可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。
Redis 6.0 之前单线程指的是 Redis 只有一个线程干活么？
不是。Redis 在处理客户端的请求时，包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理，这就是所谓的「单线程」。
其中执行命令阶段，由于 Redis 是单线程来处理命令的，所有每一条到达服务端的命令不会立刻执行，所有的命令都会进入一个 Socket 队列中，当 socket 可读则交给单线程事件分发器逐个被执行。
此外，有些命令操作可以用后台线程或子进程执行（比如数据删除、快照生成、AOF 重写）。
那 Redis 6.0 为啥要引入多线程呀？
随着硬件性能提升，Redis 的性能瓶颈可能出现网络 IO 的读写，也就是：单个线程处理网络读写的速度跟不上底层网络硬件的速度。
读写网络的 read/write 系统调用占用了Redis 执行期间大部分CPU 时间，瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向:
- 提高网络 IO 性能，典型的实现比如使用 DPDK来替代内核网络栈的方式。
- 使用多线程充分利用多核，提高网络请求读写的并行度，典型的实现比如 Memcached。
Redis 采用多个 IO 线程来处理网络请求，提高网络请求处理的并行度。
需要注意的是，Redis 多 IO 线程模型只用来处理网络读写请求，对于 Redis 的读写命令，依然是单线程处理。
这是因为，网络处理经常是瓶颈，通过多线程并行处理可提高性能。
而继续使用单线程执行读写命令，不需要为了保证 Lua 脚本、事务、等开发多线程安全机制，实现更简单。
主线程与 IO 多线程是如何实现协作呢？
流程简述：
- 主线程负责接收建立连接请求，获取 Socket 放入全局等待读处理队列。
- 主线程处理完读事件之后，通过 RR（Round Robin）将这些连接分配给这些 IO 线程。
- 主线程阻塞等待 IO 线程读取 Socket 完毕。
- 主线程通过单线程的方式执行请求命令，请求数据读取并解析完成，但并不执行。
- 主线程阻塞等待 IO 线程将数据回写 Socket 完毕。
- 解除绑定，清空等待队列。
该设计有如下特点：
- IO 线程要么同时在读 Socket，要么同时在写，不会同时读或写。
- IO 线程只负责读写 Socket 解析命令，不负责命令处理。
思路：将主线程 IO 读写任务拆分出来给一组独立的线程处理，使得多个 socket 读写可以并行化，但是 Redis 命令还是主线程串行执行。
如何开启多线程呢？
Redis 6.0 的多线程默认是禁用的，只使用主线程。如需开启需要修改 redis.conf 配置文件：io-threads-do-reads yes。
线程数是不是越多越好？
当然不是，关于线程数的设置，官方有一个建议：4 核的机器建议设置为 2 或 3 个线程，8核的建议设置为 6 个线程，线程数一定要小于机器核数。
另外，开启多线程后，还需要设置线程数，否则是不生效的。
io-threads 4总结
Redis 6.0引入多线程模型。将等待队列中的事件分给IO线程组执行，主线程阻塞。主线程轮询所有IO线程执行完读socket和解析后，按顺序执行命令，然后IO线程组回写socket。
