这是一个创建于 1450 天前的主题，其中的信息可能已经有所发展或是发生改变。
Redis 6.0 引入了多线程，我现在看了一些文章明白了大概的流程如下：
- 主线程 epoll_wait 一段时间，收集 N 个读事件后交给 I/O 线程池去处理读 socket 和解析请求
- 主线程阻塞等待 I/O 线程池完成 N 个读事件
- 主线程把解析出来的命令进行统一的处理
- 主线程把处理的结果放入缓冲区，又交给 I/O 线程池处理写 socket
- 主线程阻塞等待 I/O 线程池完成
步骤 3 命令的处理需要放在主线程统一完成我能理解，是避免多线程的竞争开销。我疑惑的是为什么步骤 2 和步骤 5 要阻塞等待，能不能改成这样：
- 主线程 epoll_wait 一段时间，收集 N 个读事件后交给 I/O 线程池去处理读 socket 和解析请求
- 主线程把解析出来的命令进行统一处理（步骤 1 的 I/O 线程池完成几个算几个），再把处理的结果放入缓冲区，交给 I/O 线程池处理写 socket
步骤 1 和步骤 2 是异步的，这样是不是效率更高？不知道我这个想法有什么问题
 | 1 ericls 2021-12-24 09:06:17 +08:00 失败了怎么办？ |
 | 2 brazz 2021-12-24 09:33:57 +08:00 1 如果是异步的那不是命令的顺序就乱了 |
 | 3 sadfQED2 2021-12-24 09:56:55 +08:00 via Android 太好了，面试再也不会有傻逼问为什么 redis 是单线程了 |
1 | 5 Jooooooooo 2021-12-24 10:10:19 +08:00 @sadfQED2 那就想多了, 为什么 redis 以前是单线程, 为什么新版改成了多线程. 这其中的缘由是什么? |
 | 6 qW7bo2FbzbC0 202112-24 10:13:39 +08:00 @sadfQED2 #3 会问，单线程有什么优点，为什么从单线程变多线程了，多线程解决了单线程的哪些弊端，有没有引入新的不可确定性 |
 | 7 hejw19970413 2021-12-24 10:25:23 +08:00 6.0 以前 从网络 IO 处理到实际的读写命令处理，都是由单个线程完成的。 问题出现 ： 随着网络硬件的性能提升，Redis 的性能瓶颈有时会出现在网络 IO 的处理上，也就是说，单个主线程处理网络请求的速度跟不上底层网络硬件的速度。 6.0 以后 Redis 的多 IO 线程只是用来处理网络请求的，对于读写命令，Redis 仍然使用单线程来处理。 为什么 主线程要阻塞 猜测大概 redis 要保证请求是严格按照到达顺序执行。 |
 | 8 sujin190 2021-12-24 10:33:06 +08:00 这写的有歧义吧，主线程完成的是 epll 事件以及命令处理，线程池完成 socket 读写级命令解析，所以主线程阻塞的意思应该只是转入 epoll wait 了，这种其实也只是针对你只有一个 socket 连接到 redis 的情况，多个连接下主线程当然是该干嘛干嘛啊 |
Select Language