redis单线程概述

一、Redis为什么使用单线程？

1.1.这种问法其实并不严谨，Redis的版本很多比如3.x、4.x、6.x,版本不同架构是不同的，不限定版本问是否单线程也不太严谨

  1. 版本3.x ，最早版本,也就是大家口口相传的redis是单线程
  2. 版本4.x，严格意义来说也不是单线程,而是负责处理客户端请求的线程是单线程,但是开始加了点多线程的东西(异步删除)
  3. 最新版本的6.0.x后,告别了大家印象中的单线程，用一种全新的多线程来解决问题。

1.2.redis里程碑式的重要版本时间线说明

redis5.0版本是直接升级到6.0版本，对于这个版本激进的升级，Redis之父antirez表现得很有信心和兴奋，所以第一时间发文来阐述6.0的一些重大功能"Redis 6.0.0 GA is out!")

1.3.Redis3.x版本采用单线程，但性能依旧很快的主要原因是什么？

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

1.4.Redis是单线程究竟是什么意思？

Redis多线程主要是指Redis的网络IO和键值对读写是由一个线程来完成的，Redis在处理客户端的请求时包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理,这就是所谓的“单线程”。这也是Redis对外提供键值存储服务的主要流程。
但是Redis的其他功能，比如持久化、异步删除、集群数据同步等等，其实是由额外的线程执行的。Redis工作线程是单线程的,但是,整个Redis来说,是多线程的

Redis采用reactor模式的网络模型，对于一个客户端请求，主线程负责完整的处理过程：

1.5.Redis 4.0之前一直采用单线程的原因是什么？

只要原因在于下面的内容：

官网地址：https://redis.io/docs/getting-started/faq/#how-can-redis-use-multiple-cpus-or-cores，对于采用单线程的原因说明如下：

上述的内容翻译后如下：

CPU 成为 Redis 瓶颈的情况并不常见，通常导致 Redis 出现瓶颈的是内存和网络。 既然CPU不会成为瓶颈，那就采用单线程的方式，但是从Redis 4.0 开始，Redis 已开始实现线程操作。仅限于在后台删除对象并阻止通过 Redis 模块实现的命令。对于后续版本，计划是使 Redis 越来越线程化。梳理后信息如下：

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

二、之前版本采用单线程如此优秀，为何在后续版本又要逐渐加入多线程呢？

2.1.单线程机制存在如下问题：

  1. 正常情况下使用del指令可以很快的删除数据，而当被删除的key是一个非常大的对象时，如包含了成千上万个元素的hash集合时，那么使用del指令就会造成Redis主线程卡顿，这就是redis3.x单线程时代最经典的故障，大key删除的头疼问题；
  2. 由于redis是单线程的,del bigKey…(等待很久这个线程才会释放，类似于加了一个synchronized锁，可以想象高并发下，程序会出现操作卡顿拥堵的问题)

2.2.如何解决单线程机制的大key删除问题

比如当我(Redis)需要删除一个很大的数据时,因为是单线程同步操作,这就会导致Redis服务卡顿，这里就使用惰性删除可以有效的避免Redis卡顿的问题，方案说明如下：

  • 于是在Redis 4.0中就新增了多线程的模块,当然此版本中的多线程主要是为了解决删除数据效率比较低的问题的
  • 因为Redis是单个主线程处理,redis之父antirez一直强调"Lazy Redis is better Redis",而lazy free的本质就是把某些cost(主要时间复制度,占用主线程cpu时间片)较高删除操作，从redis主线程剥离让bio子线程来处理，极大地减少主线阻塞时间。从而减少删除导致性能和稳定性问题
  • 在Redis 4.0就引入了多个线程来实现数据的异步惰性删除等功能,但是其处理读写请求的仍然只有一个线程,所以仍然算是狭义上的单线程。

三、redis6的多线程和IO多路复用

 对于Redis的主要的性能瓶颈是内存或者网络带宽而并非CPU，但是由于内存比较好解决，最后Redis的瓶颈可以初步定为:网络IO(到了redis6真正采用多线程来解决这个问题)，需要知道的是在 Unix网络编程中的五种IO模型：

  • Blocking IO - 阻塞IO
  • NoneBlocking IO - 非阻塞IO
  • IO multiplexing - IO多路复用
  • signal driven IO - 信号驱动IO
  • asynchronous IO - 异步IO

而redis采用的就是 ：IO multiplexing - IO多路复用，说明如下：

  • 这是IO模型的其中一种，是经典的Reactor设计模式；
  • I/O 多路复用，简单来说就是通过监测文件的读写事件再通知线程执行相关操作，保证Redis的非阻塞 I/O 能够顺利执行完成的机制；
  • 多路指的是多个socket连接,复用指的是复用一个线程。多路复用主要有三种术：select、poll、epoll；
  • epoll是最新的也是目前最好的多路复用技术。采用多路I/O复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络IO的时间消耗),且Redis在内存中操作数据的速度非常快(内存内的操作不会成为这里的性能瓶颈),主要以上两点造就了Redis具有很高的吞吐量；

Redis工作线程是单线程的,但是整个Redis来说,是多线程的， I/O的读和写本身是堵塞的，比如当socket中有数据时,Redis会通过调用先将数据从内核态空间拷贝到用户态空间,再交给Redis调用,而这个拷贝的过程就是阻塞的,当数据量越大时拷贝所需要的时间就越多,而这些操作都是基于单线程完成的，Redis采用reactor模式的网络模型，对于一个客户端请求，主线程负责完整的处理过程：

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

而在Redis 6.0将网络数据读写、请求协议解析通过多个IO线程的来处理 ，对于真正的命令执行来说,仍然使用主线程操作

  • Redis 6.0中多个io线程解决io网络问题
  • 单个线程工作，保证线程安全，高性能运行

四、Redis6.0默认是否开启了多线程？

Redis将所有数据放在内存中,内存的响应时长大约为100纳秒,对于小数据包,Redis服务器可以处理8W到10W的QPS,这也是Redis处理的极限了,对于80%的公司来说,单线程的Redis已经足够使用了，Redis6.0中,多线程机制默认是关闭的,如果需要使用多线程功能,需要在redis.conf中完成两个设置：

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

如下图：

五、redis多线程小结

  • Redis基于内存操作、数据结构简单、多路复用和非阻塞 I/O、避免了不必要的线程上下文切换等特性,在单线程的环境下依然很快

  • 但对于数据量较大的key删除还是卡顿厉害,因此在Redis 4.0引入了多线程unlink key/flushall async等命令,主要用于Redis数据的异步删除

  • Redis 6.0将网络数据读写、请求协议解析通过多个IO线程的来处理,而命令的执行依旧是由主线程串行执行的,因此在多线程下操作Redis不会出现线程安全的问题

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

posted @ 2023-03-17 10:58  酒剑仙*  阅读(49)  评论(0)    收藏  举报