关于 Redis 6.0 多线程的一点疑惑

[xing393939]

Redis 6.0 引入了多线程，我现在看了一些文章明白了大概的流程如下：

1. 主线程 epoll_wait 一段时间，收集 N 个读事件后交给 I/O 线程池去处理读 socket 和解析请求
2. 主线程阻塞等待 I/O 线程池完成 N 个读事件
3. 主线程把解析出来的命令进行统一的处理
4. 主线程把处理的结果放入缓冲区，又交给 I/O 线程池处理写 socket
5. 主线程阻塞等待 I/O 线程池完成

步骤 3 命令的处理需要放在主线程统一完成我能理解，是避免多线程的竞争开销。我疑惑的是为什么步骤 2 和步骤 5 要阻塞等待，能不能改成这样：

1. 主线程 epoll_wait 一段时间，收集 N 个读事件后交给 I/O 线程池去处理读 socket 和解析请求
2. 主线程把解析出来的命令进行统一处理（步骤 1 的 I/O 线程池完成几个算几个），再把处理的结果放入缓冲区，交给 I/O 线程池处理写 socket

步骤 1 和步骤 2 是异步的，这样是不是效率更高？不知道我这个想法有什么问题

[ericls]

失败了怎么办？

[brazz]

1 如果是异步的那不是命令的顺序就乱了

[sadfQED2]

太好了，面试再也不会有傻逼问为什么 redis 是单线程了

[douglarek]

@sadfQED2 怼，现在变成了问两个问题了

[Jooooooooo]

@sadfQED2 那就想多了, 为什么 redis 以前是单线程, 为什么新版改成了多线程. 这其中的缘由是什么?

[qW7bo2FbzbC0]

@sadfQED2 #3 会问，单线程有什么优点，为什么从单线程变多线程了，多线程解决了单线程的哪些弊端，有没有引入新的不可确定性

[hejw19970413]

6.0 以前 从网络 IO 处理到实际的读写命令处理，都是由单个线程完成的。
问题出现 ： 随着网络硬件的性能提升，Redis 的性能瓶颈有时会出现在网络 IO 的处理上，也就是说，单个主线程处理网络请求的速度跟不上底层网络硬件的速度。
6.0 以后 Redis 的多 IO 线程只是用来处理网络请求的，对于读写命令，Redis 仍然使用单线程来处理。
为什么 主线程要阻塞 猜测大概 redis 要保证请求是严格按照到达顺序执行。

[sujin190]

这写的有歧义吧，主线程完成的是 epll 事件以及命令处理，线程池完成 socket 读写级命令解析，所以主线程阻塞的意思应该只是转入 epoll wait 了，这种其实也只是针对你只有一个 socket 连接到 redis 的情况，多个连接下主线程当然是该干嘛干嘛啊