Redis 6 的多线程

1. Redis 6 的多线程

昨天和同事聊 Redis, 他问我 Redis 学的怎么样, 我说学的还行, 然后他突然问一句"你知道 Redis 现在已经支持多线程了吗? ", 我当时愣了一下, Redis 不是一直是单线程么, 怎么突然支持多线程了? 瞬间感觉被秒, 赶紧回来查阅一下相关资料, 要不然以后都不敢说自己会 Redis 了

1.1. Redis 知识回顾

我们先回顾一下 Redis 单线程模式的相关知识, 我们都知道 Redis 快的主要原因是因为 epool I/O 复用模型, 我们简单探讨一下:

• 首先, Redis 是跑在单线程中的, 所有的操作都是按照顺序线性执行的, 但是由于读写操作等待用户输入或输出都是阻塞的, 所以 I/O 操作在一般情况下往往不能直接返回, 这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务, 而 I/O 多路复用就是为了解决这个问题而出现的。
• 多路 I/O 复用模型是利用 select、poll、epoll 可以同时监听多个流的 I/O 事件的能力, 在空闲的时候, 会把当前线程阻塞掉, 当有一个或多个流有 I/O 事件时, 就从阻塞态中唤醒, 于是程序就会轮询一遍所有的流(epoll 是只轮询那些真正发出了事件的流), 并且只依次顺序的处理就绪的流, 这种做法就避免了大量的无用操作。
• 这里"多路"指的是多个网络连接, "复用"指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络 IO 的时间消耗), 且 Redis 在内存中操作数据的速度非常快, 也就是说内存内的操作不会成为影响 Redis 性能的瓶颈, 主要由以上几点造就了 Redis 具有很高的吞吐量
  下图是 Redis 的内部核心流程图(也是我能找到的比较经典的介绍 Redis 的原理图), 内部其实主要是通过双向队列和红黑树实现(图画的很详细, 里面不懂的知识, 可以直接百度, 很容易找到):

1.2. Redis 单线程

对于一个请求操作, Redis 主要做 3 件事情: 从客户端读取数据、执行 Redis 命令、回写数据给客户端(如果再准确点, 其实还包括对协议的解析)。所以主线程其实就是把所有操作的这 3 件事情, 串行一起执行, 因为是基于内存, 所以执行速度非常快:

优点 VS 缺点:

• 优势: a. 不存在锁的问题 b. 避免线程间 CPU 切换
• 缺点: a. 单线程无法利用多 CPUb. 串行操作, 某个操作"出问题"会"阻塞"后续操作

1.3. Redis 多线程

Redis 多线程的优化思路: 因为网络 I/O 在 Redis 执行期间占用了大部分 CPU 时间, 所以把网络 I/O 部分单独抽离出来, 做成多线程的方式。这里所说的多线程, 其实就是将 Redis 单线程中做的这两件事情"从客户端读取数据、回写数据给客户端"(也可以称为网络 I/O), 处理成多线程的方式, 但是"执行 Redis 命令"还是在主线程中串行执行, 这个逻辑保持不变。

可能有同学会问, 主线程和多个 I/O 线程, 都同时处理图中的"队列", 是不是会存在锁竞争的关系呢? 这里有个巧妙的设计, 就是当 epoll 获取 socket 链接时, 会将该事件先全部扔进队列中, 比如扔了 N 个事件, 这时主线程就会处于忙等 (spinlock 自旋锁的效果)状态。然后多个 I/O 线程开始去并行进行网络 I/O, 并对数据进行协议解析, 当队列全部处理完毕后, 主线程会对队列中请求串行"执行 Redis 命令", 然后清空该队列。所以整个执行流程总结下来: 主线程执行请求入队列 -> I/O 线程并行进行网络读 -> 主线程串行执行 Redis 命令 -> I/O 线程并行进行网络写 -> 主线程清空队列, 并接收下一批请求。

优点 VS 缺点

• 优点: a. 提高响应速度, 充分使用 CPU
• 缺点: a. 增加了代码复杂性

1.4. 总结

• Redis 的多路复用技术, 支持 epoll、kqueue、selector;
• 5.0 版本及以前, 处理客户端请求的线程只有一个, 串行处理;
• 6.0 版本引入了 worker Thread, 只处理网络 IO 读取和写入, 核心 IO 负责串行处理客户端指令。