Redis线程相关的问题

BinaryZx
140 阅读13分钟

一、Redis到底是单线程还是多线程

  1. Redis4之后开始慢慢支持多线程，直到redis6/7之后才稳定。
  2. Redis4的时候负责处理客户端请求的线程还是单线程，但是删除时会异步，包括AOF/RDB，也就是部分支持多线程。
  3. redis6之后，告别了单线程，用一种全新的多线程来解决问题。

image.png

image.png

二、Redis前期版本采用单线程的原因，我们所说的单线程到底是什么意思。

Redis单线程是指Redis的网络IO和键值对读写是由一个线程来完成的(这也是能保证原子性的原因)，Redis在处理客户端的请求时包括获取(Socket读)、解析、执行、内容返回(socket写)等都由一个顺序串行的主线程处理，这就是所谓的"单线程"。这也是Redis对外提供存储服务的主要流程。

image.png

但Redis的其他功能，比如持久化RBD、AOF、异步删除、集群数据同步等等，其实是由额外的线程执行的。 Redis命令工作线程是单线程的，但是，整个Redis来说是多线程的

三、Redis3.x单线程时代为什么性能依旧很快的主要原因。

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

四、Redis是单线程的，那么如何利用多个CPU内核？

这个问题官方给出了答案，大致意思就是CPU并不是Redis的性能瓶颈，而是内存或者网络，因为内存或者网络的速度和CPU的速度根本不在一个量级上的，没有可比性。就好像你还没解决基本的温饱问题呢，就想着等搬进了汤臣一品之后该怎么生活一样。

官方原话：CPU并不是您使用Redis的瓶颈，因为通常Redis要么受内存限制，要么受网络限制。例如，在使用流水线时，Redis每秒大约可以发送一百万个请求，因此，如果您的应用程序主要使用的是 O(N)或O(log(N))级别复杂度的命令，几乎不会使用过多的CPU。 但是为了最大程度的利用CPU，您可以在同一台机器上启动多个Redis实例，并将他们视为不同的服务器。在某个时候，单个核上面跑多个Redis实例还不够用，就可能需要使用多个CPU了，这种情况可以开始考虑进行分片的策略。 在Redis4.0中，我们开始使Redis有更多线程。目前仅限于在后台删除对象，以及阻止通过Redis模块实现的命令。对于将来的版本，计划是使Redis越来越线程化。 所以我们应该想办法优化内存或者网络方面。

五、Redis4之前一直使用单线程的原因：

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

六 Redis1.4之后为什么开始加入多线程了？

  1. 硬件的发展：CPU都是多核时代了，只有一个单线程对硬件的使用不是特别的
  2. 单线程的痛点：正常情况下使用del指令可以很快的删除数据，而当被删除的key是一个非常大的对象时，例如是包含了成千上万个元素的hash集合时，那么del指令就会造成Redis主线程阻塞。 这就是Redis3.x单线程时代最经典的故障，大key删除时阻塞问题。 由于redis是单线程的，del bigKey .... 等待很久线程才会释放，类似加了一个synchronized锁，你可以想象高并发下，程序会拥堵成什么样？ 如何解决？
  • 使用惰性删除可以有效避免Redis卡顿的问题
    • 比如当我删除一个很大的数据时，因为是单线程原子命令操作，这就会导致Redis服务卡顿，于是在4.0版本中就增加了新的多线程模块，当删除大key的时候，开启一个子线程去后台处理这个删除操作，不会影响主线程的执行流程，卡顿问题解决。此时的多线程只是为了解决删除数据时效率比较低的问题。严格来说这个版本其实还是单线程的。
    • 惰性删除的本质就是把某些cost(主要时间复杂度，占用主线程CPU时间片)较高的删除操作，从Redis的主线程中剥离出去，让子线程来处理，极大的减少主线程的阻塞时间。从而减少删除导致性能和稳定性问题。
# 异步删除bigKey
UNLINK k1 

# 异步清除库
FLUSHDB async

FLUSHALL async

七、Redis为什么这么快

在Redis6/7中，非常受关注的一个新特性就是多线程。 这是因为，Redis一直被大家熟知的就是他的单线程架构，虽然有些命令操作可以用后台线程或子线程执行(删除数据、AOF、RDB)。但是。从网络IO处理到实际的读写命令处理，都是由单个线程完成的。

随着网络硬件的性能提升，Redis的性能瓶颈有时会出现在网络IO的处理上，也就是说，单个主线程处理网络请求的速度已经跟不上底层网络硬件的速度。为了应对这个问题采用多个IO线程来处理网络请求，提高网络请求处理的并行度，Redis6/7就是采用的这种方法。

但是Redis的多线程IO只是用来处理网络请求的，对于读写操作命令Redis仍然使用单线程来处理。这是因为，Redis处理请求时，网络处理经常是瓶颈，通过多个IO线程并行处理网络操作，可以提升实例的整体处理性能。而继续使用单线程执行命令操作，就不用为了保证Lua脚本、事务的原子性，额外开发多线程互斥加锁机制了(不管加锁操作处理)，这样一来，Redis线程模型实现就简单了。

image.png

image.png

  1. 服务端和客户端建立Socket连接，并分配处理线程： 首先，主线程负责接收建立连接请求。当有客户端请求和实例建立Socket连接时，主线程会创建和客户端的连接，并把Socket放入全局等待队列中。紧接着，主线程通过轮询的方法把Socket连接分配给IO线程。
  2. IO线程读取并解析请求： 主线程一旦把Socket分配给IO线程，就会进入阻塞状态，等待IO线程完成客户端请求读取和解析，因为有多个IO线程在并行处理，所以这个过程很快就可以完成。
  3. 主线程执行请求操作： 等到IO线程解析完请求，主线程还是会以单线程的方式执行这些命令操作。
  4. IO线程回写Socket和主线程清空全局队列 ： 当主线程执行完请求操作后，会把需要返回的结果写入缓冲区，然后，主线程会阻塞等待IO线程把这些结果回写到Socket中，并返回给客户端。和IO线程读取和解析请求一样，IO线程回写Socket时，也是有多个线程在并发执行，所以回写Socket的速度也很快。等到IO线程回写Socket完毕，主线程会清空全局队列，等待客户端的后续操作。

从Redis6开始，新增了多线程的功能来提高I/O的读写性能，他的主要实现思路是将主线程IO读写任务拆分给一组独立的线程去执行，这样就可以使多个socket的读写可以并行化了，采用多路I/O复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络IO的时间消耗)，将最耗时的Socket的读取、请求解析、写入单独外包出去，剩下的命令执行仍然由主线程串行执行并和内存的数据交互。

image.png 结合上图可知，网络IO操作就变成多线程化了，其他核心部分仍然是线程安全的，是个不错的折中办法。

Redis6/7将网络数据读写、请求协议解析通过多个IO线程来处理，对于真正的命令执行来说，仍然使用主线程操作，一举两得，便宜占尽！！！

八、IO多路复用

一种同步的IO模型。实现一个线程监视多个文件句柄，一旦某个文件句柄(比如Socket连接)就绪就能够通知到对应应用程序进行相应的读写操作，没有文件句柄就绪时就会阻塞应用程序，从而释放CPU资源。

概念：

  • I/O：网络I/O,尤其在操作系统层面指数据在内核态和用户态之间的读写操作
  • 多路：多个客户端连接(连接就是套接字描述符，即socket或者channel)
  • 复用：复用一个或几个线程。
  • IO多路复用：就是说一个或者一组线程处理多个TCP连接，使用单进程就能够实现同时处理多个客户端的连接，无需创建或者维护过多的进程/线程。
  • 一句话：一个服务端进程可以同时处理多个套接字描述符。实现IO多路复用的模型有三种：可以分为select -> poll -> epoll 三个阶段来描述。

场景举例，理解什么是epoll

模拟一个TCP服务器处理30个客户端Socket。 假设你是一个监考老师，让30个学生解答一道竞赛考题，然后负责验收学生答卷，你有以下几个选择：

  • 轮询：按顺序挨个验收， A、B....，这中间如果有一个学生卡住，全班同学都会被耽误，用循环挨个处理Socket，根本不具有并发能力。
  • 来一个new一个，1V1服务：创建30个线程，每个分身线程检查一个学生的答案是否正确。但是如果请求有100W个呢，创建100W个线程会直接挤爆内存。
  • 响应式处理，1VN ：站在讲台上，谁解答完谁举手。C、D举手表示他们解答完毕，把C、D的答案处理完成，然后接着等.. 这就是IO复用模型，Linux下的select、poll、epoll就是干这个的。

将用户socket对应的文件描述符(FileDesciptor)注册进epoll,然后epoll帮你监听哪些socket有消息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。这样，整个过程只在调用select、poll、epoll的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是时间驱动，所谓的Reactor反应模式。

image.png

在单个线程通过记录跟踪每一个Socket(I/O流)的状态来同时管理多个I/O流，一个服务端进程可以同时处理多个套接字描述符。目的是尽量多的提高服务器的吞吐能力。 大家都用过nginx，nginx使用epoll接收请求，nginx会有很多链接进来，epoll会把他们都监视起来，然后想拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。redis类似同理，这就是IO多路复用的原理。有请求就响应，没请求不打扰。

IO多路复用 + epoll函数的使用，才是Redis为什么这么快的直接原因，而不是仅仅单线程命令+Redis安装在内存中

九、Redis7是否默认开启了多线程支持？

如果在实际应用中，发现Redis实例的CPU开销不大但吞吐量却没有提升，可以考虑使用Redis7的多线程机制，加速网络处理，进而提升实例的吞吐量。

Redis7将所有数据放在内存中，内存的响应时长大约为100纳秒，对于小数据包，Redis服务器可以处理8W到10W的QPS，这也是Redis处理的极限了，对于80%的公司来说，单线程的Redis已经足够使用了。

在Redis6.0和7以后，多线程机制默认是关闭的，如果需要使用多线程功能，需要在redis.conf文件中完成两个设置

image.png

image.png

  1. 设置io-thread-do-reads配置项为yes，表示启动多线程。
  2. 设置线程个数。关于线程数的设置，官方的建议是如果为4核的CPU，建议线程数设置为2或3，如果为8核CPU建议线程数设置为6，线程数一定要小于机器核数，线程数并不是越大越好。

总结

  • Redis自身出道就很优秀，基于内存操作、数据结构简单、多路复用和非阻塞I/O、避免了不必要的线程上下文切换等特性，在单线程的环境下依然很快。
  • 对于大数据的key删除还是卡顿厉害，因此在Redis4.0引入了多线程 unlink key / flushall async 等命令，主要用于Redis数据的异步删除。
  • 在Redis6/7中引入的I/O多线程读写，这样就可以更加高效的处理更多的任务了，Redis只是将I/O读写变成了多线程，而命令的执行依旧是由主线程串行执行，因此在多线程下操作Redis不会出现线程安全问题。
  • Redis 无论是当初的单线程设计，还是如今与当初设计相背的多线程，目的只有一个，让Redis变得越来越快。
avatar
文章
阅读
粉丝