我是 Redis，今年 11 岁了~

曾几何时我是辣么的单纯，辣么的可爱，而如今我竟背叛了当初“誓言”，决心在多线程这条路上义无反顾的一路狂奔，没错我就是你们口中那个既可爱又迷人的 Redis，你可以叫我小 R...R 😊。

一波骚操作结束，我们开始今天的正文。

我们知道在 Redis 4.0 之后就陆陆续续添加了一些多线程的功能，难道单线程不香了吗？

单线程慢吗？

Redis 的单线程曾几何时还是我们炫耀的资本，优雅又不失高效的设计，让无数的追求者为之着迷。

你要问我排第几？Nginx 是我大哥，NodeJS 是我小弟，我在家中排名老二。

我们兄弟仨可谓单线程的杰出代表，不仅演示了我们的优雅更加展现了我们的高效。

🙋‍♂️有人可能会问：为什么单线程的我，竟然如此嚣张？

家中有矿呗，Redis 单线程但性能依旧很快的主要原因有以下几点：

基于内存操作：Redis 的所有数据都存在内存中，因此所有的运算都是内存级别的，所以他的性能比较高；
数据结构简单：Redis 的数据结构比较简单，是为 Redis 专门设计的，而这些简单的数据结构的查找和操作的时间复杂度都是 O(1)，因此性能比较高；
多路复用和非阻塞 I/O：Redis 使用 I/O 多路复用功能来监听多个 socket 连接客户端，这样就可以使用一个线程连接来处理多个请求，减少线程切换带来的开销，同时也避免了 I/O 阻塞操作，从而大大提高了 Redis 的性能；
避免上下文切换：因为是单线程模型，因此就避免了不必要的上下文切换和多线程竞争，这就省去了多线程切换带来的时间和性能上的消耗，而且单线程不会导致死锁问题的发生。

来看一下我的父亲大大是如何评价我的，Redis 的 FAQ（Frequently Asked Questions，常见问题）回答了单线程的这个问题，具体内容如下：

Redis is single threaded. How can I exploit multiple CPU / cores?

It's not very frequent that CPU becomes your bottleneck with Redis, as usually Redis is either memory or network bound. For instance, using pipelining Redis running on an average Linux system can deliver even 1 million requests per second, so if your application mainly uses O(N) or O(log(N)) commands, it is hardly going to use too much CPU.

However, to maximize CPU usage you can start multiple instances of Redis in the same box and treat them as different servers. At some point a single box may not be enough anyway, so if you want to use multiple CPUs you can start thinking of some way to shard earlier.

You can find more information about using multiple Redis instances in the Partitioning page.

However with Redis 4.0 we started to make Redis more threaded. For now this is limited to deleting objects in the background, and to blocking commands implemented via Redis modules. For future releases, the plan is to make Redis more and more threaded.

详见：https://redis.io/topics/faq

他的大体意思是说 Redis 是基于内存操作的，因此他的瓶颈可能是机器的内存或者网络带宽而并非 CPU，既然 CPU 不是瓶颈，那么自然就采用单线程的解决方案了，况且使用多线程比较麻烦。但是在 Redis 4.0 中开始支持多线程了，例如后台删除等功能。

简单来说，Redis 4.0 之前一直采用单线程的主要原因有以下三个：

使用单线程模型是 Redis 的开发和维护更简单，因为单线程模型方便开发和调试；
即使使用单线程模型也并发的处理多客户端的请求，主要使用的是多路复用和非阻塞 IO；
对于 Redis 系统来说，主要的性能瓶颈是内存或者网络带宽而并非 CPU。

为什么需要多线程？

但是单线程也有单线程的苦恼，比如当我（Redis）需要删除一个很大的数据时，因为是单线程同步操作，这就会导致 Redis 服务卡顿，于是在 Redis 4.0 中就新增了多线程的模块，当然此版本中的多线程主要是为了解决删除数据效率比较低的问题的，他的相关指令有以下三个：

unlink key
flushdb async
flushall async

执行示例如下所示：

> unlink key # 后台删除某个 key
> OK # 执行成功
> flushall async # 清空所有数据
> OK # 执行成功

这样我就可以把这些坏人“瞬间”拉黑（删除）了。

所谓的“瞬间”删除其实有些夸张，只是从返回的结果来看是删除成功了，但是这只是把删除工作交给了后台的小弟（子线程）异步来删除数据了。

小贴士：正常情况下使用 del 指令可以很快的删除数据，而当被删除的 key 是一个非常大的对象时，例如时包含了成千上万个元素的 hash 集合时，那么 del 指令就会造成 Redis 主线程卡顿，因此使用惰性删除可以有效的避免 Redis 卡顿的问题。

Redis 6 中的多线程

之前在 Redis 4.0 中你说删除比较慢，骗我开大（多线程）来处理也就罢了，为毛 Redis 6.0 还要多线程嘞？

其实是这样的在 Redis 4.0 版本中虽然引入了多线程，但此版本中的多线程只能用于大数据量的异步删除，然而对于非删除操作的意义并不是很大。

但如果我们使用我们在非删除的环境下使用多线程的话就可以分摊 Redis 同步读写 I/O 的压力，以及充分的利用多核 CPU 的资源了，这样就可以有效的提升 Redis 的 QPS（Query Per Second，每秒查询率）了。

在 Redis 中虽然使用了 I/O 多路复用，并且是基于非阻塞 I/O 进行操作的，但 I/O 的读和写本身是堵塞的，比如当 socket 中有数据时，Redis 会通过调用先将数据从内核态空间拷贝到用户态空间，再交给 Redis 调用，而这个拷贝的过程就是阻塞的，当数据量越大时拷贝所需要的时间就越多，而这些操作都是基于单线程完成的。

I/O 多路复用，简单来说就是通过监测文件的读写事件，再通知线程执行相关操作，保证 Redis 的非阻塞 I/O 能够顺利执行完成的机制。

因此在 Redis 6.0 中新增了多线程的功能来提高 I/O 的读写性能，他的主要实现思路是将主线程的 IO 读写任务拆分给一组独立的线程去执行，这样就可以使多个 socket 的读写可以并行化了，但 Redis 的命令依旧是由主线程串行执行的。

需要注意的是 Redis 6.0 默认是禁用多线程的，可以通过修改 Redis 的配置文件 redis.conf 中的 io-threads-do-reads 等于 true 来开启多线程，完整配置为 io-threads-do-reads true，除此之外我们还需要设置线程的数量才能正确的开启多线程的功能，同样是修改 Redis 的配置，例如设置 io-threads 4 表示开启 4 个线程。

小贴士：关于线程数的设置，官方的建议是如果为 4 核的 CPU，建议线程数设置为 2 或 3，如果为 8 核 CPU 建议线程数设置为 6，线程数一定要小于机器核数，线程数并不是越大越好。

关于 Redis 的性能，我的父王 antirez（Redis 作者）在 RedisConf 2019 分享时曾提到，Redis 6 引入的多线程 I/O 特性对性能提升至少是一倍以上。国内也有人在阿里云使用 4 个线程的 Redis 版本和单线程的 Redis 进行比较测试，发现测试的结果和 antirez 给出的结论基本吻合，性能基本可以提高一倍。

总结

Redis 虽然依靠自己的：基于内存操作、数据结构简单、多路复用和非阻塞 I/O、避免了不必要的线程上下文切换等特性，在单线程的环境下依然很快；但对于大数据的 key 删除还是卡的飞起，因此在 Redis 4.0 引入了多线程：unlink key/flushall async 等命令，主要用于 Redis 数据的删除，而在 Redis 6.0 中引入了 I/O 多线程的读写，这样就可以更加高效的处理更多的任务****了，Redis 只是将 I/O 读写变成了多线程，而命令的执行依旧是由主线程串行执行的，因此在多线程下操作 Redis 不会出现线程安全的问题。

Redis 无论是当初的单线程设计，还是如今与当初设计相背的多线程，目的只有一个：让 Redis 变得越来越快。

所以 Redis 依旧没变，他还是那个曾经的追风少年~

最后的话

原创不易，如果觉得本文对你有用，请随手点击一个「赞」，这是对作者最大的支持与鼓励，谢谢你。

关注公众号「Java中文社群」回复“干货”，获取 50 篇原创干货 Top 榜。