1. Redis6.0之前的版本真的是单线程么

否Redis 在处理客户端的请求时包括获取 (socket 读)、解析、执⾏、内容返回 (socket 写) 等都由⼀个顺序串⾏的主线程处理这就是所谓的「单线程」。

在执行命令阶段Redis是单线程来执行命令的每一条到达读服务端的命令并不会立即执行所有的命令都会进入一个 socket 任务队列中当 socket 可读则交给单线程事件分发器逐个被执行即一个线程处理所有网络请求。如下图所示

从Redis 4.0 以后并不是严格意义上的单线程除了主线程外Redis 也有后台线程或子进程处理一些其他较为缓慢的操作例如无用连接的释放、慢IO访问和一些其他类似操作 - 清理脏数据、生成快照、AOF重写等。

2. Redis 6.0之前为什么一直不使用多线程

Redis官方是这样回答的

使用 Redis 时几乎不存在 CPU 成为瓶颈的情况Redis 主要受限于内存和网络。例如在一个普通的 Linux 系统上Redis 通过使用 pipelining 每秒可以处理 100W 个请求如果应该程序主要使用 O(N) 或 O(log(N)) 的命令它几乎不会占用太多的CPU。

如果要用到多核CPU可以搭建多个 Redis 实例来解决。

多线程模型系统复杂性能损耗高

多线程模型带来了并发读写的问题增加了系统的复杂度同时也可能存在上下文切换与竞争多线程切换甚至是加解锁导致死锁而造成的性能损耗。

Redis 通过AE事件模型以及IO多路复用等技术处理性能非常高因此没有必要使用多线程。

单线程机制使得 Redis 内部实现的复杂度大大降低Hash 的惰性 Rehash、Lpush 等等 “线程不安全” 的命令都可以无锁进行。

为什么说Redis的瓶颈不在CPU

Redis 绝大部分操作是基于内存的而且是存KVkey-value操作命令执行的速度非常快。

我们可以这么理解Redis 的数据存储在一个大的 HashMap 中而 HashMap 的优势就是查找和写入的时间复杂度都是O(1)Redis 内部采用这种结构存储数据就奠定了Redis高性能的基础。

3. Redis 6.0 为什么引入多线程

Redis 基于内存操作内存的响应时长大约为100纳秒单线程的 Redis 处理数据的极限是 80,000 到 100,000 QPS对于80%的公司来说单线程的Redis已经足够使用了。

但随着硬件性能提升Redis 的性能瓶颈可能出现⽹络 IO 的读写也就是单个线程处理⽹络读写的速度跟不上底层⽹络硬件的速度越来越复杂的业务场景也需要更大的QPS。

从 Redis 自身角度来说因为读写网络的 read/write 系统调用占用了 Redis 执行期间大部分 CPU 时间瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向

• 提⾼⽹络 IO 性能典型的实现⽐如使⽤ DPDK 来替代内核⽹络栈的⽅式。
• 使⽤多线程充分利⽤多核提⾼⽹络请求读写的并⾏度典型的实现⽐如 Memcached 。

协议栈优化的这种方式跟 Redis 关系不大支持多线程是一种最有效最便捷的操作方式。所以总结起来redis支持多线程主要就是两个原因

• 可以充分利用服务器 CPU 资源目前主线程只能利用一个核。
• 多线程任务可以分摊 Redis 同步 IO 读写负荷。

Redis 的多线程部分只是用来处理网络数据的读写和协议解析执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂需要去控制 key、lua、事务LPUSH/LPOP 等等的并发问题。

4. Redis 6.0 的多线程模型

4.1 Redis 6.0 是否默认开启了多线程模型

否Redis 6.0 的多线程是禁用的默认使用是主线程。官方建议只在机器至少有4个内核时才启用多线程模型且至少留下一个备用内核。如果需要开启多线程需修改 redis.conf 配置文件

# io-threads-do-reads no
# 改为
io-threads-do-reads yes

4.2 Redis 6.0 开启多线程后如何设置线程数

开启多线程后还需要设置线程数否则是不生效的。同样修改redis.conf配置文件

# io-threads 4
# 改为
io-threads 3

Redis 官方建议只在机器至少有4个内核时才启用多线程模型且至少留下一个备用内核。4核的机器建议设置为2或3个线程8核的建议设置为6个线程线程数一定要小于机器核数。还需要注意的是线程数并不是越大越好官方认为超过了8个基本就没什么意义了。

5. Redis多线程的实现机制

5.1 Redis 的多线程

Redis 采⽤多个 IO 线程来处理⽹络请求提⾼⽹络请求处理的并⾏度。Redis 多 IO 线程模型只⽤来处理处理网络数据的读写和协议解析对于 Redis 的读写命令依然是单线程处理。这是因为

• ⽹络处理经常是瓶颈通过多线程并⾏处理可提⾼性能。
• 继续使⽤单线程执⾏读写命令不需要为了保证 Lua 脚本、事务、等开发多线程安全机制实现更简单。

架构图如下

5.2 主线程与 IO 多线程是如何实现协作

Redis 6.0 多线程是把主线程处理网络IO和协议解析这两件事给了一组独立的线程处理使得多个 socket 读写可以并⾏化但 Redis 命令还是主线程串⾏执⾏。

主要流程如下

1. 主线程负责接收并建立多个连接请求获取 socket 后放入全局等待处理队列
2. 主线程处理完这些事件之后通过RRRound Robin 轮询将可读 socket 分配给这些 IO 线程
3. 主线程阻塞等待 IO 线程完成命令的读取、解析
4. 主线程执⾏ IO 线程读取和解析出来的 Redis 请求命令并将结果写到输出缓冲区
5. 主线程阻塞等待 IO 线程将命令执⾏结果写回 socket客户端
6. 主线程执行所有命令并清空整个等待队列等待客户端后续的请求队列。

6. Redis 6.0与老版性能对比评测

正式支持多线程Redis 6.0与老版性能对比评测

7. 多线程模型的缺陷

Redis 的多线程⽹络模型实际上并不是⼀个标准的 Multi-Reactors/Master-Workers 模型Redis 的多线程⽅案中I/O 线程任务仅仅是通过 socket 读取客户端请求命令并解析却没有真正去执⾏命令。

所有客户端命令最后还需要回到主线程去执⾏因此对多核的利⽤率并不算⾼⽽且每次主线程都必须在分配完任务之后忙轮询等待所有 I/O 线程完成任务之后才能继续执⾏其他逻辑。

Redis ⽬前的多线程⽅案更像是⼀个折中的选择既保持了原系统的兼容性⼜能利⽤多核提升 I/O 性能。