Redis网络模型

duration～2024-04-03 15:45

Redis网络模型

  • 1.网络模型
    • [1.1 用户空间和内核态空间](#1.1 用户空间和内核态空间)
    • [1.2 阻塞IO](#1.2 阻塞IO)
    • [1.3 非阻塞IO](#1.3 非阻塞IO)
    • [1.4 IO多路复用](#1.4 IO多路复用)
    • [1.5 IO多路复用-select方式](#1.5 IO多路复用-select方式)
    • [1.6 IO多路复用模型-poll模式](#1.6 IO多路复用模型-poll模式)
    • [1.7 IO多路复用模型-epoll函数](#1.7 IO多路复用模型-epoll函数)
    • [1.8 epoll中的ET和LT](#1.8 epoll中的ET和LT)
    • [1.9 基于epoll的服务器端流程](#1.9 基于epoll的服务器端流程)
    • [1.10 信号驱动](#1.10 信号驱动)
  • 2.Redis线程模型
    • [2.1 是单线程的吗？为什么使用单线程？](#2.1 是单线程的吗？为什么使用单线程？)
    • [2.2 Redis的单线程模型-Redis单线程和多线程网络模型变更](#2.2 Redis的单线程模型-Redis单线程和多线程网络模型变更)
  • 3.Redis通信协议-RESP协议
    • [3.1 发送命令格式](#3.1 发送命令格式)
    • 3.2.返回结果格式
    • [3.3 Redis通信协议-基于Socket自定义Redis的客户端](#3.3 Redis通信协议-基于Socket自定义Redis的客户端)
  • 4.内存回收
    • [4.4 过期key处理](#4.4 过期key处理)
    • [4.5 内存淘汰策略](#4.5 内存淘汰策略)

1.网络模型

1.1 用户空间和内核态空间

服务器大多都采用Linux系统，这里我们以Linux为例来讲解:

ubuntu和Centos 都是Linux的发行版，发行版可以看成对linux包了一层壳，任何Linux发行版，其系统内核都是Linux。我们的应用都需要通过Linux内核与硬件交互

用户的应用，比如redis，mysql等其实是没有办法去执行访问我们操作系统的硬件的，所以我们可以通过发行版的这个壳子去访问内核，再通过内核去访问计算机硬件

计算机硬件包括，如cpu，内存，网卡等等，内核（通过寻址空间）可以操作硬件的，但是内核需要不同设备的驱动，有了这些驱动之后，内核就可以去对计算机硬件去进行 内存管理，文件系统的管理，进程的管理等等

我们想要用户的应用来访问，计算机就必须要通过对外暴露的一些接口，才能访问到，从而简介的实现对内核的操控，但是内核本身上来说也是一个应用，所以他本身也需要一些内存，cpu等设备资源，用户应用本身也在消耗这些资源，如果不加任何限制，用户去操作随意的去操作我们的资源，就有可能导致一些冲突，甚至有可能导致我们的系统出现无法运行的问题，因此我们需要把用户和内核隔离开

进程的寻址空间划分成两部分：内核空间、用户空间

什么是寻址空间呢？我们的应用程序也好，还是内核空间也好，都是没有办法直接去物理内存的，而是通过分配一些虚拟内存映射到物理内存中，我们的内核和应用程序去访问虚拟内存的时候，就需要一个虚拟地址，这个地址是一个无符号的整数，比如一个32位的操作系统，他的带宽就是32，他的虚拟地址就是2的32次方，也就是说他寻址的范围就是0~2的32次方， 这片寻址空间对应的就是2的32个字节，就是4GB，这个4GB，会有3个GB分给用户空间，会有1GB给内核系统

在linux中，他们权限分成两个等级，0和3，用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问内核空间可以执行特权命令（Ring0），调用一切系统资源，所以一般情况下，用户的操作是运行在用户空间，而内核运行的数据是在内核空间的，而有的情况下，一个应用程序需要去调用一些特权资源，去调用一些内核空间的操作，所以此时他俩需要在用户态和内核态之间进行切换。

比如：

Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：

写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备

读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

针对这个操作：我们的用户在写读数据时，会去向内核态申请，想要读取内核的数据，而内核数据要去等待驱动程序从硬件上读取数据，当从磁盘上加载到数据之后，内核会将数据写入到内核的缓冲区中，然后再将数据拷贝到用户态的buffer中，然后再返回给应用程序，整体而言，速度慢，就是这个原因，为了加速，我们希望read也好，还是wait for data也最好都不要等待，或者时间尽量的短。

1.2 阻塞IO

在《UNIX网络编程》一书中，总结归纳了5种IO模型：

  • 阻塞IO（Blocking IO）
  • 非阻塞IO（Nonblocking IO）
  • IO多路复用（IO Multiplexing）
  • 信号驱动IO（Signal Driven IO）
  • 异步IO（Asynchronous IO）

应用程序想要去读取数据，他是无法直接去读取磁盘数据的，他需要先到内核里边去等待内核操作硬件拿到数据，这个过程就是1，是需要等待的，等到内核从磁盘上把数据加载出来之后，再把这个数据写给用户的缓存区，这个过程是2，如果是阻塞IO，那么整个过程中，用户从发起读请求开始，一直到读取到数据，都是一个阻塞状态。

具体流程如下：

用户去读取数据时，会去先发起recvform一个命令，去尝试从内核上加载数据，如果内核没有数据，那么用户就会等待，此时内核会去从硬件上读取数据，内核读取数据之后，会把数据拷贝到用户态，并且返回ok，整个过程，都是阻塞等待的，这就是阻塞IO

总结如下：

顾名思义，阻塞IO就是两个阶段都必须阻塞等待：

阶段一：

  • 用户进程尝试读取数据（比如网卡数据）
  • 此时数据尚未到达，内核需要等待数据
  • 此时用户进程也处于阻塞状态

阶段二：

  • 数据到达并拷贝到内核缓冲区，代表已就绪
  • 将内核数据拷贝到用户缓冲区
  • 拷贝过程中，用户进程依然阻塞等待
  • 拷贝完成，用户进程解除阻塞，处理数据

可以看到，阻塞IO模型中，用户进程在两个阶段都是阻塞状态。

1.3 非阻塞IO

顾名思义，非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。

阶段一：

  • 用户进程尝试读取数据（比如网卡数据）
  • 此时数据尚未到达，内核需要等待数据
  • 返回异常给用户进程
  • 用户进程拿到error后，再次尝试读取
  • 循环往复，直到数据就绪

阶段二：

  • 将内核数据拷贝到用户缓冲区
  • 拷贝过程中，用户进程依然阻塞等待
  • 拷贝完成，用户进程解除阻塞，处理数据
  • 可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

1.4 IO多路复用

无论是阻塞IO还是非阻塞IO，用户应用在一阶段都需要调用recvfrom来获取数据，差别在于无数据时的处理方案：

如果调用recvfrom时，恰好没有数据，阻塞IO会使CPU阻塞，非阻塞IO使CPU空转，都不能充分发挥CPU的作用。

如果调用recvfrom时，恰好有数据，则用户进程可以直接进入第二阶段，读取并处理数据

所以怎么看起来以上两种方式性能都不好

而在单线程情况下，只能依次处理IO事件，如果正在处理的IO事件恰好未就绪（数据不可读或不可写），线程就会被阻塞，所有IO事件都必须等待，性能自然会很差。

就比如服务员给顾客点餐，分两步：

  • 顾客思考要吃什么（等待数据就绪）
  • 顾客想好了，开始点餐（读取数据）

要提高效率有几种办法？

方案一：增加更多服务员（多线程）

方案二：不排队，谁想好了吃什么（数据就绪了），服务员就给谁点餐（用户应用就去读取数据）

那么问题来了：用户进程如何知道内核中数据是否就绪呢？

所以接下来就需要详细的来解决多路复用模型是如何知道到底怎么知道内核数据是否就绪的问题了

这个问题的解决依赖于提出的

文件描述符（File Descriptor）：简称FD，是一个从0 开始的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字（Socket）。

通过FD，我们的网络模型可以利用一个线程监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

阶段一：

  • 用户进程调用select，指定要监听的FD集合
  • 核监听FD对应的多个socket
  • 任意一个或多个socket数据就绪则返回readable
  • 此过程中用户进程阻塞

阶段二：

  • 用户进程找到就绪的socket
  • 依次调用recvfrom读取数据
  • 内核将数据拷贝到用户空间
  • 用户进程处理数据

当用户去读取数据的时候，不再去直接调用recvfrom了，而是调用select的函数，select函数会将需要监听的数据交给内核，由内核去检查这些数据是否就绪了，如果说这个数据就绪了，就会通知应用程序数据就绪，然后来读取数据，再从内核中把数据拷贝给用户态，完成数据处理，如果N多个FD一个都没处理完，此时就进行等待。

用IO复用模式，可以确保去读数据的时候，数据是一定存在的，他的效率比原来的阻塞IO和非阻塞IO性能都要高

IO多路复用是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。不过监听FD的方式、通知的方式又有多种实现，常见的有：

  • select
  • poll
  • epoll

其中select和pool相当于是当被监听的数据准备好之后，他会把你监听的FD整个数据都发给你，你需要到整个FD中去找，哪些是处理好了的，需要通过遍历的方式，所以性能也并不是那么好

而epoll，则相当于内核准备好了之后，他会把准备好的数据，直接发给你，咱们就省去了遍历的动作。

1.5 IO多路复用-select方式

select是Linux最早是由的I/O多路复用技术：

简单说，就是我们把需要处理的数据封装成FD，然后在用户态时创建一个fd的集合（这个集合的大小是要监听的那个FD的最大值+1，但是大小整体是有限制的 ），这个集合的长度大小是有限制的，同时在这个集合中，标明出来我们要控制哪些数据，

比如要监听的数据，是1,2,5三个数据，此时会执行select函数，然后将整个fd发给内核态，内核态会去遍历用户态传递过来的数据，如果发现这里边都数据都没有就绪，就休眠，直到有数据准备好时，就会被唤醒，唤醒之后，再次遍历一遍，看看谁准备好了，然后再将处理掉没有准备好的数据，最后再将这个FD集合写回到用户态中去，此时用户态就知道了，奥，有人准备好了，但是对于用户态而言，并不知道谁处理好了，所以用户态也需要去进行遍历，然后找到对应准备好数据的节点，再去发起读请求，我们会发现，这种模式下他虽然比阻塞IO和非阻塞IO好，但是依然有些麻烦的事情， 比如说频繁的传递fd集合，频繁的去遍历FD等问题

1.6 IO多路复用模型-poll模式

poll模式对select模式做了简单改进，但性能提升不明显，部分关键代码如下：

IO流程：

  • 创建pollfd数组，向其中添加关注的fd信息，数组大小自定义
  • 调用poll函数，将pollfd数组拷贝到内核空间，转链表存储，无上限
  • 内核遍历fd，判断是否就绪
  • 数据就绪或超时后，拷贝pollfd数组到用户空间，返回就绪fd数量n
  • 用户进程判断n是否大于0,大于0则遍历pollfd数组，找到就绪的fd

与select对比：

  • select模式中的fd_set大小固定为1024，而pollfd在内核中采用链表，理论上无上限
  • 监听FD越多，每次遍历消耗时间也越久，性能反而会下降

1.7 IO多路复用模型-epoll函数

epoll模式是对select和poll的改进，它提供了三个函数：

第一个是：eventpoll的函数，他内部包含两个东西

一个是：

1、红黑树-> 记录的事要监听的FD

2、一个是链表->一个链表，记录的是就绪的FD

紧接着调用epoll_ctl操作，将要监听的数据添加到红黑树上去，并且给每个fd设置一个监听函数，这个函数会在fd数据就绪时触发，就是准备好了，现在就把fd把数据添加到list_head中去

3、调用epoll_wait函数

就去等待，在用户态创建一个空的events数组，当就绪之后，我们的回调函数会把数据添加到list_head中去，当调用这个函数的时候，会去检查list_head，当然这个过程需要参考配置的等待时间，可以等一定时间，也可以一直等， 如果在此过程中，检查到了list_head中有数据会将数据添加到链表中，此时将数据放入到events数组中，并且返回对应的操作的数量，用户态的此时收到响应后，从events中拿到对应准备好的数据的节点，再去调用方法去拿数据。

小总结：

select模式存在的三个问题：

  • 能监听的FD最大不超过1024
  • 每次select都需要把所有要监听的FD都拷贝到内核空间
  • 每次都要遍历所有FD来判断就绪状态

poll模式的问题：

  • poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降

epoll模式中如何解决这些问题的？

  • 基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高
  • 每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epol_wait无需传递任何参数，无需重复拷贝FD到内核空间
  • 利用ep_poll_callback机制来监听FD状态，无需遍历所有FD，因此性能不会随监听的FD数量增多而下降

1.8 epoll中的ET和LT

当FD有数据可读时，我们调用epoll_wait（或者select、poll）可以得到通知。但是事件通知的模式有两种：

  • LevelTriggered：简称LT，也叫做水平触发。只要某个FD中有数据可读，每次调用epoll_wait都会得到通知。
  • EdgeTriggered：简称ET，也叫做边沿触发。只有在某个FD有状态变化时，调用epoll_wait才会被通知。

举个栗子：

  • 假设一个客户端socket对应的FD已经注册到了epoll实例中
  • 客户端socket发送了2kb的数据
  • 服务端调用epoll_wait，得到通知说FD就绪
  • 服务端从FD读取了1kb数据回到步骤3（再次调用epoll_wait，形成循环）

结论

如果我们采用LT模式，因为FD中仍有1kb数据，则第⑤步依然会返回结果，并且得到通知

如果我们采用ET模式，因为第③步已经消费了FD可读事件，第⑤步FD状态没有变化，因此epoll_wait不会返回，数据无法读取，客户端响应超时。

1.9 基于epoll的服务器端流程

我们来梳理一下这张图

服务器启动以后，服务端会去调用epoll_create，创建一个epoll实例，epoll实例中包含两个数据

1、红黑树（为空）：rb_root 用来去记录需要被监听的FD

2、链表（为空）：list_head，用来存放已经就绪的FD

创建好了之后，会去调用epoll_ctl函数，此函数会会将需要监听的数据添加到rb_root中去，并且对当前这些存在于红黑树的节点设置回调函数，当这些被监听的数据一旦准备完成，就会被调用，而调用的结果就是将红黑树的fd添加到list_head中去(但是此时并没有完成)

3、当第二步完成后，就会调用epoll_wait函数，这个函数会去校验是否有数据准备完毕（因为数据一旦准备就绪，就会被回调函数添加到list_head中），在等待了一段时间后(可以进行配置)，如果等够了超时时间，则返回没有数据，如果有，则进一步判断当前是什么事件，如果是建立连接时间，则调用accept() 接受客户端socket，拿到建立连接的socket，然后建立起来连接，如果是其他事件，则把数据进行写出

1.10 信号驱动

信号驱动IO是与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待。

阶段一：

  • 用户进程调用sigaction，注册信号处理函数
  • 内核返回成功，开始监听FD
  • 用户进程不阻塞等待，可以执行其它业务
  • 当内核数据就绪后，回调用户进程的SIGIO处理函数

阶段二：

  • 收到SIGIO回调信号
  • 调用recvfrom，读取
  • 内核将数据拷贝到用户空间
  • 用户进程处理数据

当有大量IO操作时，信号较多，SIGIO处理函数不能及时处理可能导致信号队列溢出，而且内核空间与用户空间的频繁信号交互性能也较低。

1 异步IO

这种方式，不仅仅是用户态在试图读取数据后，不阻塞，而且当内核的数据准备完成后，也不会阻塞

他会由内核将所有数据处理完成后，由内核将数据写入到用户态中，然后才算完成，所以性能极高，不会有任何阻塞，全部都由内核完成，可以看到，异步IO模型中，用户进程在两个阶段都是非阻塞状态。

2 对比

最后用一幅图，来说明他们之间的区别

2.Redis线程模型

2.1 是单线程的吗？为什么使用单线程？

Redis到底是单线程还是多线程？

  • 如果仅仅聊Redis的核心业务部分（命令处理），答案是单线程
  • 如果是聊整个Redis，那么答案就是多线程

在Redis版本迭代过程中，在两个重要的时间节点上引入了多线程的支持：

  • Redis v4.0：引入多线程异步处理一些耗时较旧的任务，例如异步删除命令unlink
  • Redis v6.0：在核心网络模型中引入 多线程，进一步提高对于多核CPU的利用率

因此，对于Redis的核心网络模型，在Redis 6.0之前确实都是单线程。是利用epoll（Linux系统）这样的IO多路复用技术在事件循环中不断处理客户端情况。

为什么Redis要选择单线程？

  • 抛开持久化不谈，Redis是纯 内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，因此多线程并不会带来巨大的性能提升。
  • 多线程会导致过多的上下文切换，带来不必要的开销
  • 引入多线程会面临线程安全问题，必然要引入线程锁这样的安全手段，实现复杂度增高，而且性能也会大打折扣

2.2 Redis的单线程模型-Redis单线程和多线程网络模型变更

当我们的客户端想要去连接我们服务器，会去先到IO多路复用模型去进行排队，会有一个连接应答处理器，他会去接受读请求，然后又把读请求注册到具体模型中去，此时这些建立起来的连接，如果是客户端请求处理器去进行执行命令时，他会去把数据读取出来，然后把数据放入到client中， clinet去解析当前的命令转化为redis认识的命令，接下来就开始处理这些命令，从redis中的command中找到这些命令，然后就真正的去操作对应的数据了，当数据操作完成后，会去找到命令回复处理器，再由他将数据写出。

3.Redis通信协议-RESP协议

几乎所有的主流编程语言都有 Redis的客户端(http://redis.io/clients)，不考虑Redis 非常流行的原因，如果站在技术的角度看原因还有两个:

  1. 客户端与服务端之间的通信协议是在 TCP 协议之上构建的。
  2. Redis制定了RESP(REdis Serialization Protocol，Redis序列化协议)实现客户端与服务端的正常交互，这种协议简单高效，既能够被机器解析，又容易被人类识别。

例如客户端发送一条set hello world命令给服务端，按照RESP 的标准，客户端需要将其封装为如下格式(每行用\r\n分隔):

sql 复制代码 
*3
$3
SET
$5
hello
$5
world

这样 Redis服务端能够按照RESP将其解析为set hello world命令，执行后回复的格式如下:

json 复制代码 
+OK

可以看到除了命令(sethelloworld)和返回结果(0K)本身还包含了一些特殊字符以及数字，下面将对这些格式进行说明。

3.1 发送命令格式

RESP的规定一条命令的格式如下，CRLF代表 "\r\n" :

sql 复制代码 
*<参数数量> CRLF
$<参数1的字节数量> CRLF
<参数 1> CRLF
...
$<参数的字节数量>CRLF
<参数 N> CRLF

依然以 set hell world 这条命令进行说明。参数数量为3个，因此第一行为:

java 复制代码 
*3

参数字节数分别是 3 5 5，因此后面几行为:

sql 复制代码 
$3
SET
$5
hello
$5
world

有一点要注意的是，上面只是格式化显示的结果，实际传输格式为如下代码，整个过程如图所示:

sh 复制代码 
*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n

3.2.返回结果格式

Redis 的返回结果类型分为以下五种，如图所示:

  • 状态回复:在 RESP 中第一个字节为"+"。
  • 错误回复:在RESP 中第一个字节为"-"。
  • 整数回复:在 RESP 中第一个字节为":"。
  • 字符串回复:在 RESP 中第一个字节为"$"。
  • 多条字符串回复:在RESP 中第一个字节为"*"。

我们知道 redis-c1i只能看到最终的执行结果，那是因为redis-cli本身就是按照RESP进行结果解析的，所以看不到中间结果，redis-cli.c源码对命令结果的解析结构如下:

c 复制代码 
static sds cliFormatReplyTTY(redisReply *r，char *pre@x){
	sds out=sdsempty();
	switch(r->type)(
	Case REDIS REPLY_ERROR:
	// 处理错误回复
	Case REDIS REPLY STATUS:
	// 处理状态回复
	Case REDIS REPLY_INTEGER:
	// 处理整数回复
	Case REDIS REPLY_STRING:
	//处理字符串回复
	Case REDIS_REPLY_NIL:
	//处理空
	Case REDIS_REPLY_ARRAY:
	//处理多条字符串回复
	return out;
}

例如执行 set hello world，返回结果是 0K，并不能看到加号:

sh 复制代码 
127.0.0.1:6379> set hello world
OK

为了看到Reds服务端返回的"真正"结果，可以使用nc命令、telnet 命令、甚写一个socket 程序进行模拟。下面以nc命令进行演示，首先使用nc 127.0.0.6379连接到 Redis:

sh 复制代码 
nc 127.0.0.1 6379

状态回复:set hello world的返回结果为 + OK:

sh 复制代码 
set hello world
+OK

错误回复:由于sethx这条命令不存在，那么返回结果就是"-"号加上错误消息

sh 复制代码 
sethx
-ERR unknown command 'sethx'

整数回复:当命令的执行结果是整数时，返回结果就是整数回复，例如incr、exists、del、dbsize返回结果都是整数，例如执行 incr counter 返回结果就是 ":" 加上整数:

sh 复制代码 
incr counter
:1

字符串回复:当命令的执行结果是字符串时，返回结果就是字符串回复。例如get、hget 返回结果都是字符串，例如get hello 的结果为 "$5\r\nworld\r\n":

sh 复制代码 
get hello
$5
world

多条字符串回复:当命令的执行结果是多条字符串时，返回结果就是多条字符串回复例如 mget、hgetall、lrange 等命令会返回多个结果，例如下面操作:

首先使用 mset 设置多个键值对:

sh 复制代码 
mset java jedis python redis-py
+OK

然后执行 mget 命令返回多个结果，第一个 *2 代表返回结果的个数，后面的格式是和字符串回复一致的:

sh 复制代码 
mget java python
*2
$5
jedis
$8
redis-py

有一点需要注意，无论是字符串回复还是多条字符串回复，如果有nil值，那么会返回 $-1。

例如，对一个不存在的键执行 get 操作，返回结果为:

sql 复制代码 
get not_exist_key
$-1

如果批量操作中包含一条为 nil值的结果，那么返回结果如下:

sh 复制代码 
mget hello not_exist_key java
*3
$5
world
$-1
$5
jedis

有了 RESP 提供的发送命令和返回结果的协议格式，各种编程语言就可以利用其来实现相应的 Redis 客户端。

3.3 Redis通信协议-基于Socket自定义Redis的客户端

Redis支持TCP通信，因此我们可以使用Socket来模拟客户端，与Redis服务端建立连接：

java 复制代码 
public class Main {

    static Socket s;
    static PrintWriter writer;
    static BufferedReader reader;

    public static void main(String[] args) {
        try {
            // 1.建立连接
            String host = "192.168.150.101";
            int port = 6379;
            s = new Socket(host, port);
            // 2.获取输出流、输入流
            writer = new PrintWriter(new OutputStreamWriter(s.getOutputStream(), StandardCharsets.UTF_8));
            reader = new BufferedReader(new InputStreamReader(s.getInputStream(), StandardCharsets.UTF_8));

            // 3.发出请求
            // 3.1.获取授权 auth 123456
            sendRequest("auth", "1232456");
            Object obj = handleResponse();
            System.out.println("obj = " + obj);

            // 3.2.set name hello
            sendRequest("set", "name", "hello");
            // 4.解析响应
            obj = handleResponse();
            System.out.println("obj = " + obj);

            // 3.2.set name hello
            sendRequest("get", "name");
            // 4.解析响应
            obj = handleResponse();
            System.out.println("obj = " + obj);

            // 3.2.set name hello
            sendRequest("mget", "name", "num", "msg");
            // 4.解析响应
            obj = handleResponse();
            System.out.println("obj = " + obj);
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            // 5.释放连接
            try {
                if (reader != null) reader.close();
                if (writer != null) writer.close();
                if (s != null) s.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

    private static Object handleResponse() throws IOException {
        // 读取首字节
        int prefix = reader.read();
        // 判断数据类型标示
        switch (prefix) {
            case '+': // 单行字符串，直接读一行
                return reader.readLine();
            case '-': // 异常，也读一行
                throw new RuntimeException(reader.readLine());
            case ':': // 数字
                return Long.parseLong(reader.readLine());
            case '$': // 多行字符串
                // 先读长度
                int len = Integer.parseInt(reader.readLine());
                if (len == -1) {
                    return null;
                }
                if (len == 0) {
                    return "";
                }
                // 再读数据,读len个字节。我们假设没有特殊字符，所以读一行（简化）
                return reader.readLine();
            case '*':
                return readBulkString();
            default:
                throw new RuntimeException("错误的数据格式！");
        }
    }

    private static Object readBulkString() throws IOException {
        // 获取数组大小
        int len = Integer.parseInt(reader.readLine());
        if (len <= 0) {
            return null;
        }
        // 定义集合，接收多个元素
        List<Object> list = new ArrayList<>(len);
        // 遍历，依次读取每个元素
        for (int i = 0; i < len; i++) {
            list.add(handleResponse());
        }
        return list;
    }

    // set name hello
    private static void sendRequest(String ... args) {
        writer.println("*" + args.length);
        for (String arg : args) {
            writer.println("$" + arg.getBytes(StandardCharsets.UTF_8).length);
            writer.println(arg);
        }
        writer.flush();
    }
}

4.内存回收

4.4 过期key处理

Redis之所以性能强，最主要的原因就是基于内存存储。然而单节点的Redis其内存大小不宜过大，会影响持久化或主从同步性能。

我们可以通过修改配置文件来设置Redis的最大内存：

当内存使用达到上限时，就无法存储更多数据了。为了解决这个问题，Redis提供了一些策略实现内存回收：

内存过期策略

通过expire命令给Redis的key设置TTL（存活时间）：

可以发现，当key的TTL到期以后，再次访问name返回的是nil，说明这个key已经不存在了，对应的内存也得到释放。从而起到内存回收的目的。

Redis本身是一个典型的key-value内存存储数据库，因此所有的key、value都保存在之前学习过的Dict结构中。不过在其database结构体中，有两个Dict：一个用来记录key-value；另一个用来记录key-TTL。

这里有两个问题需要我们思考：

Redis是如何知道一个key是否过期呢？

利用两个Dict分别记录key-value对及key-ttl对

是不是TTL到期就立即删除了呢？

惰性删除

惰性删除：顾明思议并不是在TTL到期后就立刻删除，而是在访问一个key的时候，检查该key的存活时间，如果已经过期才执行删除。

周期删除

周期删除：顾明思议是通过一个定时任务，周期性的抽样部分过期的key，然后执行删除。执行周期有两种：

Redis服务初始化函数initServer()中设置定时任务，按照server.hz的频率来执行过期key清理，模式为SLOW

Redis的每个事件循环前会调用beforeSleep()函数，执行过期key清理，模式为FAST

周期删除：顾明思议是通过一个定时任务，周期性的抽样部分过期的key，然后执行删除。执行周期有两种：

Redis服务初始化函数initServer()中设置定时任务，按照server.hz的频率来执行过期key清理，模式为SLOW

Redis的每个事件循环前会调用beforeSleep()函数，执行过期key清理，模式为FAST

SLOW模式规则：

  • 执行频率受server.hz影响，默认为10，即每秒执行10次，每个执行周期100ms。
  • 执行清理耗时不超过一次执行周期的25%.默认slow模式耗时不超过25ms
  • 逐个遍历db，逐个遍历db中的bucket，抽取20个key判断是否过期
  • 如果没达到时间上限（25ms）并且过期key比例大于10%，再进行一次抽样，否则结束
  • FAST模式规则（过期key比例小于10%不执行 ）：
  • 执行频率受beforeSleep()调用频率影响，但两次FAST模式间隔不低于2ms
  • 执行清理耗时不超过1ms
  • 逐个遍历db，逐个遍历db中的bucket，抽取20个key判断是否过期
    如果没达到时间上限（1ms）并且过期key比例大于10%，再进行一次抽样，否则结束

小总结：

RedisKey的TTL记录方式：

在RedisDB中通过一个Dict记录每个Key的TTL时间

过期key的删除策略：

惰性清理：每次查找key时判断是否过期，如果过期则删除

定期清理：定期抽样部分key，判断是否过期，如果过期则删除。

定期清理的两种模式：

SLOW模式执行频率默认为10，每次不超过25ms

FAST模式执行频率不固定，但两次间隔不低于2ms，每次耗时不超过1ms

4.5 内存淘汰策略

内存淘汰：就是当Redis内存使用达到设置的上限时，主动挑选部分key删除以释放更多内存的流程。Redis会在处理客户端命令的方法processCommand()中尝试做内存淘汰：

淘汰策略

Redis支持8种不同策略来选择要删除的key：

  • noeviction： 不淘汰任何key，但是内存满时不允许写入新数据，默认就是这种策略。
  • volatile-ttl： 对设置了TTL的key，比较key的剩余TTL值，TTL越小越先被淘汰
  • allkeys-random：对全体key ，随机进行淘汰。也就是直接从db->dict中随机挑选
  • volatile-random：对设置了TTL的key ，随机进行淘汰。也就是从db->expires中随机挑选。
  • allkeys-lru： 对全体key，基于LRU算法进行淘汰
  • volatile-lru： 对设置了TTL的key，基于LRU算法进行淘汰
  • allkeys-lfu： 对全体key，基于LFU算法进行淘汰
  • volatile-lfu： 对设置了TTL的key，基于LFI算法进行淘汰
    比较容易混淆的有两个：
    • LRU（Least Recently Used），最少最近使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
    • LFU（Least Frequently Used），最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。

Redis的数据都会被封装为RedisObject结构：

LFU的访问次数之所以叫做逻辑访问次数，是因为并不是每次key被访问都计数，而是通过运算：

  • 生成0~1之间的随机数R
  • 计算 (旧次数 * lfu_log_factor + 1)，记录为P
  • 如果 R < P ，则计数器 + 1，且最大不超过255
  • 访问次数会随时间衰减，距离上一次访问时间每隔 lfu_decay_time 分钟，计数器 -1

最后用一副图来描述当前的这个流程吧

相关推荐
会员源码网25 分钟前
理财源码开发：单语言深耕还是多语言融合？看完这篇不踩坑
网络·个人开发
麦聪聊数据1 小时前
Web 原生架构如何重塑企业级数据库协作流？
数据库·sql·低代码·架构
未来之窗软件服务1 小时前
数据库优化提速(四)新加坡房产系统开发数据库表结构—仙盟创梦IDE
数据库·数据库优化·计算机软考
米羊1211 小时前
已有安全措施确认（上）
大数据·网络
ManThink Technology2 小时前
如何使用EBHelper 简化EdgeBus的代码编写？
java·前端·网络
Goat恶霸詹姆斯2 小时前
mysql常用语句
数据库·mysql·oracle
大模型玩家七七3 小时前
梯度累积真的省显存吗？它换走的是什么成本
java·javascript·数据库·人工智能·深度学习
曾经的三心草3 小时前
redis-9-哨兵
数据库·redis·bootstrap
明哥说编程3 小时前
Dataverse自定义表查询优化：D365集成大数据量提速实战【索引配置】
数据库·查询优化·dataverse·dataverse自定义表·索引配置·d365集成·大数据量提速
珠海西格电力科技3 小时前
微电网能量平衡理论的实现条件在不同场景下有哪些差异？
运维·服务器·网络·人工智能·云计算·智慧城市
热门推荐
01GitHub 镜像站点02Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services03openclaw配置教程（linux+局域网ollama）04OpenClaw Chrome扩展使用教程 - 浏览器中继控制05Linux下V2Ray安装配置指南06UV安装并设置国内源07Claude Code Skills 实用使用手册08一文了解国产算子编程语言 TileLang，TileLang 对国产开源生态的影响与启示09使用 1panel面板 部署 php网站10让 Trae IDE 智能体 “读懂”文档 Excel+PDF+DOCX ：mcp-documents-reader 工具使用指南