[021-22].Redis的线程模型原理分析

Java学习大纲

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

一、Redis使用的线程分析：

1.1.基于版本分析Redis使用单线程还是多线程？？

1.在Redis中有3.x、4.x、6.x中有很多个版本，在不同的版中，架构也是不同的，在Redis版本5.x之前的版本中，redis使用的是单线程。在版本6.0.x之后，用一种全新的多线程 来解决问题
2.我们平常说的Redis是单线的含义是指：Redis的网络IO和键值对读写是由一个线程来完成的，Redis在处理客户端的请求时包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理，这就是所谓的“单线程”。这也是Redis对外提供键值存储服务的主要流程
3.Redis的其他功能，比如持久化RDB、AOF、异步删除、集群数据同步等等，其实是由额外的线程执行的。所以总的来说，Redis命令工作线程是单线程的，但是对整个Redis来说，是多线程的

1.2.Redis3.x使用单线程但性能依旧很快的原因

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

1.3.Redis 4.0 之前为何一直采用单线程：

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

1.4.Redis为何选择加入了多线程：

a.单线程的问题

1.CPU出现多核的，但是redis还是单线程的，那么就会导致redis对硬件的使用不充分！
2.大key删除的头疼问题：正常情况下使用 del 指令可以很快的删除数据，而当被删除的 key 是一个非常大的对象时，时包含了成千上万个元素的 hash 集合时，那么 del 指令就会造成 Redis 主线程卡顿。这就是redis3.x单线程时代最经典的故障，大key删除的头疼问题，由于redis是单线程的，del bigKey …，等待很久这个线程才会释放，类似加了一个synchronized锁，那么可以想象得到在高并发下，程序堵成什么样子！！！

b.解决措施：

1.使用惰性删除 可有效避免Redis卡顿的问题：
- 比如当我（Redis）需要删除一个很大的数据时，因为是单线程原子命令操作，这就会导致 Redis 服务卡顿，于是在 Redis 4.0 中就新增了多线程的模块，当然此版本中的多线程主要是为了解决删除数据效率比较低的问题的
- unlink key：异步删除key
- flushdb async：把删除工作交给了后台的小弟（子线程）异步来删除数据了
- flushall async
2.在 Redis 4.0 中就新增了多线程来实现数据的异步惰性删除等功能，但是其处理读写请求然只有一个线程，所以仍然是侠义上的单线程

二、Unix网络编程中的五种IO模型

模型1：Blocking IO-阻塞IO

拿不到结果不回去

模型2：NoneBlocking IO -非阻塞IO

模型3：IO multiplexing - IO多路复用

a.Linux世界一些皆文件

1.文件描述符,简称FD
- 文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念
- 文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表
- 当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符
- 在程序设计中，文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统
- 客户端与Linux建立起了Socket连接后，会拿到一个文件描述符
2.文件句柄：

b.IO多路复用是什么:

1.概念解释：
- I/O∶网络I/O，尤其在操作系统层面指数据在内核态和用户态之间的读写操作
- 多路:多个客户端连接（连接就是套接字描述符，即socket或者channel)
- 复用:复用一个或几个线程。
2.IO多路复用是—种同步的IO模型，实现一个线程监视多个文件句柄，一旦某个文件句柄就绪就能够通知到对应的应用程序进行相应的读写操作，没有文件句柄就绪时就会阻塞应用程序，从而释放CPU资源
3.IO多路复用：也就是说一个或一组线程处理多个TCP连接,使用单进程就能够实现同时处理多个客户端的连接，无需创建或者维护过多的进程/线程。一句话解释就是：一个服务端进程可以同时处理多个套接字描述符。实现IO多路复用的模型有3种:可以分select->poll->epoll三个阶段来描述:

c.场景体验：

1.模拟一个tcp服务器处理30个客户socket：
假设你是一个监考老师，让30个学生解答一道竞赛考题，然后负责验收学生答卷，你有下面几个选择：
- 第一种选择(轮询)：按顺序逐个验收，先验收A，然后是B，之后是C、D。。。这中间如果有一个学生卡住，全班都会被耽误,你用循环挨个处理socket，根本不具有并发能力。
- 第二种选择(来一个new一个，1对1服务)：你创建30个分身线程，每个分身线程检查一个学生的答案是否正确。这种类似于为每一个用户创建一个进程或者线程处理连接。
- 第三种选择(响应式处理，1对多服务)，你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理E和A。。。这种就是IO复用模型。Linux下的select、poll和epoll就是干这个的

d.IO多路复用模型：

1.将用户socket对应的文件描述符(FileDescriptor)注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。这样，整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor反应模式。
2.在单个线程通过记录跟踪每一个Sockek(I/O流)的状态来同时管理多个I/O流. 一个服务端进程可以同时处理多个套接字描述符。目的是尽量多的提高服务器的吞吐能力。大家都用过nginx，nginx使用epoll接收请求，ngnix会有很多链接进来， epoll会把他们都监视起来，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。redis类似同理，这就是IO多路复用原理，有请求就响应，没请求不打扰

e.总结

只使用一个服务端进程可以同时处理多个套接字描述符连接

模型4：signal driven io- 信号驱动

模型5：asynchronous IO - 异步IO

三、Redis6/7的多线程特性和IO多路复用入门篇

3.1.定位Redis性能瓶颈：

1.对于Redis主要的性能瓶颈是:内存或者网络带宽而并非CPU
2.对于内存来说，现在很容易达到要求，价格便宜，所以最后Redis的瓶颈可以初步定为网络IO

3.2.分析Redis性能瓶颈：

a.Redis6/7真正的多线程登场：

在Redis6/7中，非常受关注的第一个新特性就是多线程。这是因为，Redis一直被大家熟知的就是它的单线程架构，虽然有些命令操作可以用后台线程或子进程执行（比如数据删除、快照生成、AOF重写）。但是，从网络IO处理到实际的读写命令处理，都是由单个线程完成的。
随着网络硬件的性能提升，Redis的性能瓶颈有时会出现在网络IO的处理上，也就是说，单个主线程处理网络请求的速度跟不上底层网络硬件的速度，为了应对这个问题采用多个IO线程来处理网络请求，提高网络请求处理的并行度，Redis6/7就是采用的这种方法
Redis的多IO线程只是用来处理网络请求的，对于读写操作命令Redis仍然使用单线程来处理。这是因为，Redis处理请求时，网络处理经常是瓶颈，通过多个IO线程并行处理网络操作，可以提升实例的整体处理性能。而继续使用单线程执行命令操作，就不用为了保证Lua脚本、事务的原子性，额外开发多线程互斥加锁机制了(不管加锁操作处理)，这样一来，Redis线程模型实现就简单了

b.主线程和IO线程怎么协作完成请求处理的

阶段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完毕时，主线程会清空全局队列，等待客户端的后续请求！

3.3.面试：Redis为何这么快

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

3.4.主线程和IO线程是怎么协作完成请求处理的：

在这里插入图片描述

结论：

四、Redis7默认是否开启了多线程：

4.1.概述：

在实际的使中，如果发现Redis实例CPU开销不大但是吞吐量却没有提升。可以考虑使用Redis7的多线程机制，加速网络处理，进而提升实例的吞吐量
- Redis7将所有数据放在内存中，内存的响应时长大约为100纳秒，对于小数据包，Redis服务器可以处理8W到10W的QPS，这也是Redis处理的极限了，对于80%的公司来说，单线程的Redis已经足够使用了
- 在Redis6.0及7后，多线程机制默认是关闭的，如果需要使用多线程功能，需要在redis.conf中完成两个设置