文章目录
- 概述
- 一、Redis线程模型演进
-
- [1. 经典单线程模型（Redis 4.0前）](#1. 经典单线程模型（Redis 4.0前）)
- [2. 多线程优化演进](#2. 多线程优化演进)
- 二、数据持久化机制
-
- [1. AOF（Append Only File）](#1. AOF（Append Only File）)
- [2. RDB（Redis Database）](#2. RDB（Redis Database）)
- [3. 混合持久化（Redis 4.0+）](#3. 混合持久化（Redis 4.0+）)
- 三、高可用架构设计
-
- [1. 主从复制（Replication）](#1. 主从复制（Replication）)
- [2. 哨兵模式（Sentinel）](#2. 哨兵模式（Sentinel）)
- [3. Redis Cluster（分布式集群）](#3. Redis Cluster（分布式集群）)
- 四、总结
概述
Redis作为当前最流行的缓存中间件，凭借其高性能和高可用性成为分布式系统中的核心组件。接下来 将深入剖析Redis的线程模型、数据持久化机制及高可用方案，全面掌握Redis的核心原理。
一、Redis线程模型演进
1. 经典单线程模型（Redis 4.0前）
核心特点：
- 单线程处理网络I/O与键值操作
- 避免线程竞争与锁开销
- 基于I/O多路复用处理高并发请求
Redis 是单线程的，主要是指 Redis 的网络 I/O 线程，以及键值的 SET 和 GET 等读写操作都是由一个线程来完成的。但 Redis 的持久化、集群同步等操作，则是由另外的线程来执行的。
高性能秘诀
- 全内存操作
- 高效数据结构（哈希表、跳表）
- 非阻塞I/O多路复用（Epoll/Kqueue）
2. 多线程优化演进
- Redis 4.0 ：引入异步删除（
UNLINK、FLUSHDB ASYNC） - Redis 6.0 ：网络I/O多线程化（默认关闭）
- 核心改进：主线程处理命令，多线程处理网络数据读写
- 性能提升：网络密集型场景吞吐量提升2倍
虽然 Redis 一直是单线程模型，但是在 Redis 6.0 版本之后，也采用了多个 I/O 线程来处理网络请求，这是因为随着网络硬件的性能提升，Redis 的性能瓶颈有时会出现在网络 I/O 的处理上，所以为了提高网络请求处理的并行度，Redis 6.0 对于网络请求采用多线程来处理。但是对于读写命令，Redis 仍然使用单线程来处理。
二、数据持久化机制
1. AOF（Append Only File）
通常情况下，关系型数据库（如 MySQL）的日志都是"写前日志"（Write Ahead Log, WAL），也就是说，在实际写数据之前，先把修改的数据记到日志文件中，以便当出现故障时进行恢复，比如 MySQL 的 redo log（重做日志），记录的就是修改后的数据。
而 AOF 里记录的是 Redis 收到的每一条命令，这些命令是以文本形式保存的，不同的是，Redis 的 AOF 日志的记录顺序与传统关系型数据库正好相反，它是写后日志，"写后"是指 Redis 要先执行命令，把数据写入内存，然后再记录日志到文件。
实现原理：
- 记录所有写命令（文本格式）
- 写后日志机制（先执行命令再记录日志）
优缺点：
- ✅ 数据完整性高
- ❌ 文件体积大、恢复速度慢
- ❌ 同步策略（Always/Everysec/No）影响性能与可靠性
2. RDB（Redis Database）
因为 AOF 日志记录的是操作命令，不是实际的数据，所以用 AOF 方法做故障恢复时，需要全量把日志都执行一遍，一旦日志非常多，势必会造成 Redis 的恢复操作缓慢。
为了解决这个问题，Redis 增加了 RDB 内存快照（所谓内存快照，就是将内存中的某一时刻状态以数据的形式记录在磁盘中）的操作，它即可以保证可靠性，又能在宕机时实现快速恢复。
和 AOF 不同的是，RDB 记录 Redis 某一时刻的数据，而不是操作，所以在做数据恢复时候，只需要直接把 RDB 文件读入内存，完成快速恢复。
实现原理：
- 生成内存快照（二进制压缩文件）
- 支持
SAVE（阻塞）与BGSAVE（后台子进程）
RDB 做快照时会阻塞线程吗？
因为 Redis 的单线程模型决定了它所有操作都要尽量避免阻塞主线程，所以对于 RDB 快照也不例外，这关系到是否会降低 Redis 的性能。
为了解决这个问题，Redis 提供了两个命令来生成 RDB 快照文件，分别是 save 和 bgsave。save 命令在主线程中执行，会导致阻塞。而 bgsave 命令则会创建一个子进程，用于写入 RDB 文件的操作，避免了对主线程的阻塞，这也是 Redis RDB 的默认配置。
RDB 做快照的时候数据能修改吗？
如果在执行快照的过程中，数据如果能被修改或者不能被修改都会带来什么影响？
-
如果此时可以执行写操作：意味着 Redis 还能正常处理写操作，就可能出现正在执行快照的数据是已经被修改了的情况；
-
如果此时不可以执行写操作：意味着 Redis 的所有写操作都得等到快照执行完成之后才能执行，那么就又出现了阻塞主线程的问题。
那Redis 是如何解决这个问题的呢？ 它利用了 bgsave 的子进程，具体操作如下：
-
如果主线程执行读操作，则主线程和 bgsave 子进程互相不影响；
-
如果主线程执行写操作，则被修改的数据会复制一份副本，然后 bgsave 子进程会把该副本数据写入 RDB 文件，在这个过程中，主线程仍然可以直接修改原来的数据。
核心优势：
- ⚡️ 快速恢复（秒级重启）
- 💾 紧凑存储（适合备份）
- ⚠️ 数据可能丢失（两次快照间宕机）
3. 混合持久化（Redis 4.0+）
Redis 对 RDB 的执行频率非常重要，因为这会影响快照数据的完整性以及 Redis 的稳定性，所以在 Redis 4.0 后，增加了 AOF 和 RDB 混合的数据持久化机制： 把数据以 RDB 的方式写入文件，再将后续的操作命令以 AOF 的格式存入文件，既保证了 Redis 重启速度，又降低数据丢失风险。
创新设计：
- RDB快照 + 增量AOF日志
- 重启时先加载RDB，再重放AOF
- 优势：兼顾启动速度与数据完整性
三、高可用架构设计
1. 主从复制（Replication）
核心机制：
- 一主多从架构
- 全量同步（RDB） + 增量同步（命令传播）
- 读写分离提升读吞吐量
痛点：
- 主节点故障需手动切换
2. 哨兵模式（Sentinel）
核心功能：
- 监控节点健康状态
- 自动故障转移（选举新主节点）
- 客户端服务发现
3. Redis Cluster（分布式集群）
核心特性：
- 数据分片（16384哈希槽）
- 自动故障转移
- 无中心节点设计
哈希槽分配策略：
- 自动分配 ：
CLUSTER CREATE平均分布 - 手动分配 ：
CLUSTER ADDSLOTS精准控制
Redis Cluster 方案采用哈希槽（Hash Slot），来处理数据和实例之间的映射关系。在 Redis Cluster 方案中，一个切片集群共有 16384 个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中，具体执行过程分为两大步。
-
根据键值对的 key，按照
CRC16算法计算一个 16 bit 的值。 -
再用 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽。
剩下的一个问题就是，这些哈希槽怎么被映射到具体的 Redis 实例上的呢？有两种方案。
-
平均分配： 在使用 cluster create 命令创建 Redis 集群时，Redis 会自动把所有哈希槽平均分布到集群实例上。比如集群中有 9 个实例，则每个实例上槽的个数为 16384/9 个。
-
手动分配： 可以使用 cluster meet 命令手动建立实例间的连接，组成集群，再使用 cluster addslots 命令，指定每个实例上的哈希槽个数 。
为了方便理解，通过一张图来解释数据、哈希槽，以及实例三者的映射分布关系。
四、总结
通过深入理解Redis的线程模型、持久化机制与高可用架构，开发者能够更好地设计高性能、高可靠的缓存方案。在实际应用中，需根据业务场景灵活选择持久化策略与集群方案，持续优化系统表现
