Redis单线程&多线程

Redis 单线程 VS 多线程

思考：

• Redis为什么选择单线程？

• 既然单线程那么好，为什么逐渐又加入了多线程特性？

• Redis7是否默认开启了多线程？

• Redis — version

1. Redis 3.X版本，是最早的版本，这个时候的redis就是单线程的
2. Redis 4.X版本，严格意义上吗来说不是单线程的，负责处理客户端请求的线程是单线程的，但是开始加了多线程的东西(异步删除)
3. Redis 6.0版本，以及Redis 7.0版本后，告别了大家印象中的单线程，而是一种全新的多线程来解决问题。

• 如何理解Redis的单线程？

​ 这里需要注意一个问题，我们所说的Redis的单线程，不是指Redis程序真的只有一个线程。这里所说的单线程，指的是Redis处理客户端发来的数据操作请求**（增删改查），只会使用一个线程去执行**。但是实际上，Redis在执行其他操作的时候，可能会开启多个进程或线程，比如说持久化。Redis执行BGSAVE指令，**进行快照持久化时，就会fork出一个子进程，然后子进程去创建快照，完成持久化操作。**更形象的例子就是，**Redis会像Java那样进行lock unlocak这种加锁解锁的操作吗？**很明显是没有的，那面对高并发怎么办？单线程

​ 一句话总结 ：Redis命令工作线程是单线程的，但是，整个Redis是多线程的。

• Redis 3.X的时候，单线程时代依旧性能很快的主要原因是什么？

1. 基于内存操作 ：Redis的所有数据都存在内存中，因此所有的运算都是内存级别的，所以Redis的性能高。
2. 数据结构简单 ：Redis的所有数据结构是专门设计的，而这些简单的数据结构的查找和操作的时间复杂度大部分时间都是O(1)。
3. 多路复用和非阻塞IO ：Redis使用 I/O多路复用来监听多个socket连接客户端，这样就可以使用一个线程连接来处理多个请求，减少线程切换带来的性能损耗，同时也避免了 I/O阻塞等情况。
4. 避免上下文切换 ：因为是单线程模型，因此就避免了不必要的上下文切换和多线程竞争，这就省去了多线程切换带来的时间和性能上的消耗。不用加锁，不用wait notify等操作。

• Redis是单线程的，那Redis如何利用多个CPU呢？

​ 官方回答 ：CPU并不是使用Redis的瓶颈，因为通常Redis要么受内存限制，要么受网络限制。例如，使用平均Linux系统上运行的流水线Redis每秒可以发送一百万个请求，因此，如果您的应用程序主要使用 O(N) 或 O(logN) 命令，则几乎不会使用过多的CPU资源。但是为了最大程度的利用CPU，您可以在同一框中启动多个Redis实例，并将他们视为不同的服务器，在某个时候，单个Redis看你还不够，因此如果您要使用多个CPU，则可以开始考虑更早的进行分片的方式。

​ 我的理解 ：我们知道，Redis将数据存放在内存当中，这也就意味着，Redis在操作数据时，不需要进行磁盘I/O。磁盘I/O是一个比较耗时的操作，所以对于需要进行磁盘I/O的程序，我们可以使用多线程，在某个线程进行I/O时，CPU切换到当前程序的其他线程执行，以此减少CPU的等待时间。**而Redis直接操作内存中的数据，所以使用多线程并不能有效提升效率，相反，使用多线程反倒会因为需要进行线程的切换而降低效率。**使用多线程的话，多个线程间进行同步，保证线程的安全，也是需要开销的。尤其是Redis的数据结构都是一些实现较为简单的集合结构，若使用多线程，将会频繁地发生线程冲突，线程的竞争频率较高，反倒会拖慢Redis的响应速度。

• Redis单线程的痛点是什么？

​ 正常情况下，使用 del 指令可以很快的删除数据，而当被删除的 key 是一个非常大的对象的时候，如一个包含了成千上万个元素的hash 集合进行 del 时，del 指令就会造成 Redis 主线程卡顿。**这就是redis 3.X 单线程时代最经典的故障，大 key 删除的头疼问题。**由于redis 是单线程，del bigKey … 等待很久这个线程才会被释放，就像加了synchronized锁，你可以想象一下高并发下，程序会怎么样

• 如何解决Redis单线程的痛点？

​ unlink key 命令 ：当我们在 Redis 中需要删除一个很大的数据的时候，因为是单线程原子命令操作，这就会导致 Redis 服务卡顿。于是在 Redis 4.0 中就新增了多线程的模块，当然此版本中的多线程主要是为了解决删除数据效率比较低的问题才出现的多线程的概念。而 unlink key 指令就是将这个删除工作交给了后台的 子线程 异步的来删除数据了。

Redis的多线程模型请再看看这一篇 https://blog.csdn.net/m0_73302761/article/details/131872806?spm=1001.2014.3001.5501