Redis 是多线程还是单线程？这是一个经典的面试题目，个人认为也是对Redis架构设计的一个简单概要。
本文主要是对 Redis 架构进行一个简要的梳理分析和概要，而不在细节上进行深入的探讨




# 总览
首先，Redis 并不是简单的多线程或是单线程，他既是一个单线程程序，又是一个多线程程序，两者的关系并非非此即彼，而且在其中还穿插着异步线程。我们可以通过一张简单的模型图来大致概括一下 Redis 的线程结构：

![Redis多线程架构图.drawio.png](https://www.blog.aeside.top/static/img/126ea7c9d8325eecc2bd1cca4cf3f403.Redis%C3%A5%C2%A4%C2%9A%C3%A7%C2%BA%C2%BF%C3%A7%C2%A8%C2%8B%C3%A6%C2%9E%C2%B6%C3%A6%C2%9E%C2%84%C3%A5%C2%9B%C2%BE.drawio.webp)


# Redis 的单线程
Redis的“单线程”主要是指Redis的**网络IO**和**键值对读写**是由**一个线程**来完成的，Redis在处理客户端的请求时包括获取（socket读）、解析、执行、内容返回（socket写）等都由一个**顺序串行的主线程处理**（第一篇介绍过的那些原子的命令），这也是Redis对外提供键值存储服务的主要流程。

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

![file-20250726090401203.png](https://www.blog.aeside.top/static/img/faa3320e65c53adb5007b67e576269bd.file-20250726090401203.webp)
> 补充：
> 
> Reactor 模式是一种**并发模型**，在这种模型中，**主线程（Reactor）**避免了由于等待一或多个并发事件（比如 I/O 操作）的完成而无法继续工作的阻塞。通过使用非阻塞 I/O 操作和事件通知，主线程在并发操作完成时得到通知。
> 
> 一般来说，Reactor 模式的工作流程如下：
> 
> 1. 应用程序将需要**监听的 I/O 事件（比如 socket 的可读、可写事件）注册到 Reactor 中，并且关联对应的处理事件。
> 2. Reactor 不断地**轮询**这些事件，当某个事件到达的时候（比如 socket 中有数据可读），Reactor 将这个事件对应的处理事件唤醒，交由一个工作线程（或者称之为 EventHandler）去处理。
> 3. 工作线程处理完相应的事件后，通知 Reactor **继续监听**这个事件。
> 
> 这种模型非常适合于**大并发，少逻辑**的网络程序中，比如 Nginx 中就用到了这种设计模式。通过这种方式，一个线程可以处理很多连接的事件，而不需要为每个连接都创建一个线程，这样就可以避免线程切换的开销，并且可以更有效地使用系统资源。

# Redis 的异步
Redis 作为一款内存型数据库，大多数读写操作的执行速度都非常快。然而，仍有一些操作相对耗时，例如持久化、空间清理、删除大对象（Big Key）等。这类操作如果在主线程中同步执行，可能会显著阻塞 Redis 对后续请求的响应，从而影响整体性能。

通过分析可以发现，这些操作往往对实时性要求并不高。因此，我们可以将它们**异步化处理**，即通过后台线程或子进程的方式执行这些耗时任务，从而避免阻塞主线程，提升 Redis 的响应能力和吞吐量。

- **持久化操作**：如 RDB 快照生成、AOF 重写，通过 fork 子进程完成，主线程不被阻塞。
- **惰性删除（Lazy Free）**：使用 `UNLINK` 命令删除大对象时，实际内存释放由后台线程异步完成。
- **过期键清理**：Redis 采用惰性删除与定期删除相结合的方式，部分清理任务异步执行。
- **主从复制**：写命令的同步是异步进行的，提升主节点的响应效率。

# Redis 的多线程
Redis 的多线程架构在使用方面上，主要还是在IO处理上面。首先，在 Redis 早期完全单线程的结构中，面对IO瓶颈是通过多路复用的方式解决的。

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

但是随着 Redis QPS增多，一个线程同时处理的IO请求变得越来越多。举个极端的例子，当一个线程通过IO多路复用，同时监控1k个socket接口，这时候瓶颈反而到了CPU上面。因此，我们就需要映入多个线程来进行负载均衡，但是依然是一个线程通过IO多路复用对多个socket。

# 总结

![](https://www.blog.aeside.top/static/img/126ea7c9d8325eecc2bd1cca4cf3f403.Rediså¤çº¿ç¨æ¶æå¾.drawio.webp)

Redis 的多线程设计主要致力于解决**网络 I/O 在高并发下的性能瓶颈**，而非为了并行执行 Redis 命令。它采用了**主线程 + 多个 I/O 子线程**的混合模型，既保留了 Redis 的一致性优势，又显著提升了整体吞吐能力。

- **主线程**负责接收客户端连接、解析命令以及执行核心逻辑操作，确保数据的一致性和命令执行的原子性。
- **I/O 子线程**用于加速网络请求的读取和响应写回过程，特别是在高并发场景下，通过多个I/O子线程来均衡负载，提高处理效率。

与此同时，Redis 还引入了**异步处理机制**以应对那些相对耗时但对实时性要求不高的任务，例如持久化、空间清理和删除大对象（Big Key）。这些操作如果同步执行会阻塞主线程，影响系统性能。因此，Redis 采用以下策略进行优化：

- **持久化操作**：如 RDB 快照生成和 AOF 文件重写，通过 fork 子进程完成，避免阻塞主线程。
- **惰性删除（Lazy Free）**：使用 `UNLINK` 命令删除大对象时，实际内存释放由后台线程异步完成。
- **过期键清理**：Redis 结合惰性删除与定期删除的方式，部分清理任务异步执行，减少对主线程的影响。

综上所述，Redis 不仅通过多线程架构提升网络 I/O 性能，还利用异步处理机制优化了耗时任务的管理。这种综合设计使得 Redis 能够在保持高性能的同时，提供稳定可靠的服务。

# 参考资料
【Redis】高级篇： 一篇文章讲清楚Redis的单线程和多线程 - 秦她的菜的文章 - 知乎
https://zhuanlan.zhihu.com/p/646111642

Redis 线程模型


# 概念

JVM 全称是 Java Virtual Machine，中文译名 Java虚拟机。
JVM 本质上是一个运行在计算机上的**程序**，他的职责是运**行Java字节码文件**。

## 三大功能
解释运行、内存管理和即时编译——JVM：我今天运行起来只为三件事（
- 解释运行![[assets/JVM/file-20250508211934315.png]]
- 内存管理
	- ~~Java学长这招可太狠了~~，内存的分配和回收都交给JVM来处理，对程序员编写代码友好（jyy老师曾经说程序员是不可信的......因为会犯错）
- 即时编译
	对热点代码进行优化，提升执行效率。即时编译可以说是提升Java程序性能最核心的手段
	
	- Why？——优点
		- 实现跨平台
		- 提高性能
			- 热点代码——虚拟机是智能的，在运行的时候会发现某个方法被高频调用，就会对这段代码进行优化（在此处不做过多深入）
				- 优化——代码逻辑结构优化，更适合机器运行
				- 缓存——缓存解释过代码的字节码

## JVM组成
![[assets/JVM/file-20250508215423528.png]]
- 类加载器系统
	- 核心组件类加载器，负责将字节码文件(.class)中的内容加载到内存中
- 运行时数据区
	- JVM管理的内存，创建出来的对象、类的信息等等内容都会放在这块区域中
- 执行引擎
	- 解释器
		- 将字节码指令解释成机器码
	- 即时编译器（JIT Compiler）
		- 将热点代码（高频执行的代码）编译为本地机器码，提升性能
	- 垃圾回收器
		- 回收不再使用的对象

- 本地方法接口（JNI, Java Native Interface）
	- 调用本地使用C/C++编译好的方法，本地方法在Java中声明时，都会带上native关键字

## JMM 内存模型
JMM（Java Memory Model），官方名称为**运行时数据区域**。

JVM在执行 Java 程序的过程中会把它管理的内存划分成若干个不同的数据区域。这里我们根据线程是否共享，可以简单地分为**主内存和工作内存**。![[assets/JVM/file-20250721162725868.png]]

- 主内存
	- 所有线程共享的区域，包含了所有共享变量、类信息、实例对象等，也就是运行时数据区域中的堆和方法区的数据。
- 工作内存
	- 每个线程在执行时的私有空间，包含了局部变量表、操作数栈等，也就是运行时数据区域中的程序计数器和栈的数据。

从上面主内存和工作内存的区分，当我们将JVM视作一个操作系统，两个内存。我们可以认为一个是程序里面的内存，负责运行程序中的变量、方法等数据；另外一个是我们计算机的内存，负责在我们电脑开机运行过程中数据的管理

### 工作内存
工作内存，也就是线程私有的内存，分为三个区域：
- 程序计数器
- 虚拟机栈
- 本地方法栈

#### 程序计数器
功能类似于CPU的PC计数器，但是在JVM中不同于CPU中的PC计数器，JVM中的程序计数器是**每个线程独立拥有一个的**。

如此一来，各线程之间计数器互不影响，独立存储，便于线程切换后的恢复

程序计数器主要有两个作用：
- 字节码解释器通过改变程序计数器来依次**读取指令** *（如：顺序执行、选择、循环、异常处理）*
- 多线程下，记录当前线程执行的位置

#### 虚拟机栈
Java 虚拟机栈（后文简称栈）也是线程私有的，它的生命周期和线程相同，随着线程的创建而创建，随着线程的死亡而死亡。

回顾操作系统角度的JVM，虚拟机栈在这里作为程序（工作内存）的内部栈。一个程序在运行过程中是会调用很多方法，然后在各个方法之间进入返回，而栈的结构就类似方法之间的进出。

![[assets/JVM/file-20250721164540439.png]]
栈的每次压入弹出，就相当于我们进入方法、计算处理，然后返回结果。而在方法中又有许多信息需要存储和读取，所以栈中又有许多栈帧，每个栈帧中都拥有：
- 局部变量表
	- **局部变量表** 主要存放了编译期可知的各种数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference 类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。
- 操作数栈
	- 主要作为方法调用的中转站使用，用于存放方法执行过程中产生的中间计算结果。另外，计算过程中产生的临时变量也会放在操作数栈中。
- 动态链接
	- 主要服务一个方法需要调用其他方法的场景。Class 文件的常量池里保存有大量的符号引用比如方法引用的符号引用。当一个方法要调用其他方法，需要将常量池中指向方法的符号引用转化为其在内存地址中的直接引用。动态链接的作用就是为了将符号引用转换为调用方法的直接引用，这个过程也被称为 **动态连接** 。
- 方法返回地址

#### 本地方法栈
和虚拟机栈所发挥的作用非常相似，区别是：**虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。** 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。

本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。

### 主内存
主内存是所有线程共享的内存

首先要问为什么为什么登录用『redis+session』，首先就得问他爹『为什么登录要用Session』！问他爹为什么用Session就得问他爷爷『为什么要有Session和Coookie』！问为什么要有他两就得问他曾爷爷『HTTP协议中的无状态补充——Session』！

为什么为什么为什么？！？！本文章今天就来抛砖引玉，串一串这几个东西：Redis+JWT、Session&Cookie、HTTP的无状态协议。究竟是道德的沦丧？还是人性的堕落？今夜本文为你一究到底！
用Token替代Session

## 问题
刚才我们已经初略提出了我们问题的雏形，我们简单梳理一下我们的问题。

为什么我们要使用『redis+session登录验证』？
因为Session受限与一个服务器进程

为什么我们要用『Session登录验证』？
因为我们要实现用户登录状态的保持，避免重复登录

为什么我们要『使用Session来实现状态保持』？
因为Session&Cookie实现了HTTP会话状态管理。补充了HTTP无连接特性下，状态保持的欠缺

# 为什么我们要『使用Session来实现状态保持』？
首先来回答第一个问题：为什么我们要『使用Session来实现状态保持』？

有因必有果，存在即合理。在计算机的世界中，每一项技术都是由人来选择、使用的，而这里面必然由它被选中的理由，而Session也如此。

### 背景
遥想天地之初，互联网的世界尚且还是一片荒漠，计算机处理能力低下，存储容量小，网速很慢。万维网的开宗老祖——蒂姆·伯纳斯·李（Tim Berners-Lee），在 1989 年，他发表了一篇论文，提出了在互联网上构建超链接文档系统的构想，在这篇论文里他确立了三项关键技术：

- URI：统一资源标识符，作为互联网上资源的唯一标识
- HTML：超文本标记语言，描述超文本文档
- HTTP：超文本传输协议，用来传输超文本

此文一出，顿觉Web天地宽，开天辟地了我们当今Web世界的技术。由于在早期的互联网中，大多数资源都还是静态的，而为了便于服务器和客户端处理，服务器响应之后，会立刻关闭连接。然而，这却为未来的互联网埋下了一场腥风血雨~

#### 跟一条金鱼讨论人生，HTTP和无状态协议
随着互联网和计算机的发展，我们的网页渐渐变得丰富，甚至是万能了起来（你甚至可以在网页上运行一个OS......）。而在网页会话的状态上，我们也渐渐有了需求——在登录淘宝购物时，要先登录才让购物，如果按HTTP无状态的特性来说，我们几乎每一个动作都需要登录一次，太不现实了。

#### 让金鱼拥有记忆，Session和Cookie
然鹅，魔高一丈，道高一尺！我们的卢姥爷—— *卢·蒙特利* 于1994年发明了Cookie，后续引出了我们今天的所要讨论的Session，为HTTP协议的**无状态连接**提供了**有状态**的补充。

通过实现一个**逻辑上的有状态**（是的，逻辑上的有状态，与WebSocket这样的技术不同，如果说WebSocket是两人在房间里面谈话，那么 Cookie 就是两人相互写信，不过彼此记得之前的谈话），我们就可以避免反复重复传输一部分数据，比如说登录认证信息。

>引用一下这两篇文章，对这部分内容讲解得很详细，由于本文重点不在这里，不过多篇幅讲解~~（虽然已经水了一大半）~~
>https://zhuanlan.zhihu.com/p/99986478
>https://www.cnblogs.com/cn-oldboy/p/12543519.html

# 抽象中的Session，Session与Cookie一个水果比香蕉好吃的故事
为什么Session要保留他模棱两可的诞生来头，其实是为了隐藏Session与Cookie不可告人的关系.....各位有所不知，这段经历早就美化过了......他真正的身份，就是......~~（后面忘了，总之就是卖钩子了）~~

言归正传，Cookie的出现是要早于Session的。先是发明了Cookie实现HTTP无状态的补充，而后在开发中，我们逐渐将**Cookie**从具体的实现**抽象**为前后端交互的一个**概念——Session**，而这也便是**Session**的身世，一个抽象的概念，名为 **“会话”**（或者说是一种**机制**）

## Tomcat中的HttpSession，狸猫换太子的故事
所以说，如果之前问出 **“Cookie和Session之间的区别？”** 这个问题，实际上是不合理的。毕竟一个抽象概念和他的实现要怎么比较呢？准确地来说，我们的问题应该被描述成 **“Cookie与Tomcat中Session的实现（HttpSession）的区别？”**

简单地来说 Cookie & HttpSession 这个问题，他的实现是基于类似这样的一个过程：
- 浏览器第一次访问服务器，服务器会响应回来一个SessionID，来维护本次的**会话**
- 浏览器接收到响应回来的SessionID，放入到Cookie中，成功地在双方之间建立一个“Session”。注意，此Session非彼Session，**是一个抽象意义上的逻辑的Session**（一次会话），而不是一个具体的Session（Tomcat中的HttpSession）
- 然后在后续的双方通信，每次浏览器带上Cookie访问服务器。服务器读取Cookie中的SessionID，服务器就能根据SessionID查询到对应的HttpSession，**继续两者之间逻辑上的会话**（实际应用上就是不用再进行登录验证）

总而言之，这里我们不重在讲解Cookie与Session之间的区别，而是重在提出Session这个抽象的概念“会话”，与他具体的实现（Tomcat的HttpSession）区分开。而在这里，也郑重地提出一句话：**Web一日尚存，Session永世不灭！**
 
# Session的变迁，从HttpSession到Redis + Session
计算机发展的洪流滚滚向前，历史的车轮无情地从Session&Cookie上碾过。当面对千家万户接入互联网的时候，数以万计的访问请求向我们的服务器袭来，面对这样的变遇，服务器的未来又该何去何从？

而历史告诉我们，服务器选择了分布式系统——通过组成**服务器集群**。但是，面对服务器集群，Session&Cookie的机制却~~犹如八十岁老太用手机一样~~束手无策——由于基于Tomcat的HttpSession与Cookie的机制，是基于一个进程中的，不能做到在多个进程，甚至是多台服务器上实现HttpSession的共享。

千呼万唤始出来，我们的Redis此时便派上用场了——**通过Redis实现分布式系统下的服务器集群Session共享**。

Tomcat中的HttpSession从本质上来看，也不过是我们Java进程中的一个数据结构，在内存上就是一组数据，所以从理论上来讲，我们可以把 HTTPSession 写入到 Redis 进行存储并统一管理。

由于本文章主要意在探讨原理，而且Redis+Session的实现在网上一搜一大把，在这里具体就不做讲解了。

讲完了Redis+Session，就到此为止了吗？不，我们还要谈谈他的另外一个兄弟——Token & JWT

# 登录验证从Session到Token，从有状态回到无状态

灵感戛然而止......