Redis on pipo's site

Redis 生产问题

Sun, 19 Oct 2025 00:00:00 +0000

缓存穿透

指使用非法 key 进行请求, 这个 key 不存在于 Redis 缓存和数据库中. 导致数据库一直忙于处理非法 key 的查询请求.

1. 缓存空值

使用 Redis 缓存空值,将不存在的 key 加入缓存,之后直接在 Redis 被拦截.

优点 :实现简单,成本低.
缺点 : 大量不同非法 key 访问会占用大量 redis 缓存.
改进: 给空值 key 设置较短的过期时间或者加入布隆过滤器.

2. 布隆过滤器

使用布隆过滤器首先判断当前请求的数据是否存在, 若不存在直接拦截, “存在"后继续交由 redis 进行. 优点: bloomfilter 使用了散列算法"存储”,占用空间极小,速度快. 缺点: bloomfilter 会出现假阳性,同时无法删除数据. 改进: 使用缓存空值兜底,同时定期刷新写入真实的数据.

缓存击穿

1. 分布式锁

通过加入分布式只允许一个线程同时去访问数据库进行缓存重建,其他线程等待缓存好的数据. 步骤: A. redis 缓存未命中,尝试获取锁 B. 获取锁成功,进行双重检查 C. 查询数据库 D.重新加入 Redis 缓存 (若为空则构造空值)

缺点:

导致大量用户被堵塞,体验较差.
锁竞争激烈时，性能下降
如果锁未正确释放（如程序崩溃），可能导致死锁

改进:

使用 Redis 的 SET key value NX PX milliseconds 命令原子操作加锁。
加锁失败时，不要无限等待，可以返回“稍后再试”或“默认值”。

2.逻辑过期 + 异步更新

在非强一致性场景下,缓存数据时加入逻辑过期时间,若发生过期则先返回旧数据,同时获取分布式锁进行异步更新缓存. 步骤: A. redis 缓存命中, 但此时逻辑过期 B. 返回旧数据,同时尝试获取锁. C. 开启子线程,进行双重检查 D. 重构缓存缺点:

复杂度较高, 需要维护逻辑过期字段、异步线程、锁机制
用户可能无法及时获取到最新数据.
内存占用略高,因为缓存不会真正过期，除非手动清理。

改进:

对缓存设置较长的过期时间,大于逻辑过期时间.

3. 缓存预热

针对热点数据提前预热，将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。

缓存雪崩

指缓存内同时出现大量 key 过期或者 Redis 奔溃重启,没有缓存任何key,导致大量的请求都直接落到了数据库上，对数据库造成了巨大的压力。

1. 随机过期时间

通过在 Redis 重构缓存时在过期时间中加入随机抖动使得过期时间均匀分散,避免了大量 key 同时过期的情况.

2. Redis 集群

通过构建 Redis 主从架构+哨兵机制实现, 当主节点下线后,哨兵会自动把从节点提升为主节点. 多个节点保证了不会出现缓存全部消失的情况.

**服务降级 & 熔断

当数据库压力过大时：

返回默认值（如“系统繁忙，请稍后再试”）。
启用本地缓存（如 Caffeine）作为二级缓存。
使用限流（如 Sentinel、Hystrix）保护数据库。

3.预热数据

Redis RDB & AOF

Fri, 17 Oct 2025 00:00:00 +0000

RDB

RDB是对 Redis 某一瞬间保存的全量快照,本质上是一份二进制文件,用来在 Redis 重启或丢失数据后进行恢复,通常用作数据恢复、主从全量同步以及定期备份.

执行方式

1.手动

可以通过 `SAVE` 与 `BGSAVE` 手动执行 RDB 备份, `SAVE` 命令会在主线程内进行备份操作,此时Redis主线程会被堵塞直到写入 RDB 完成.
使用 `BGSAVE` 时 则是通过 `fork` 一个子线程进行写时复制写入硬盘,不会造成 Redis 主线程堵塞.

Copy-On-Write（写时复制） 是一种 优化内存使用和提升性能的系统级技术，广泛用于操作系统（如 Linux）、数据库、虚拟化等领域。

多个进程/线程共享同一份物理内存，只有当某个进程试图“修改”数据时，才真正复制一份私有副本。

读操作：直接共享原始数据，无需复制；

写操作：触发复制，之后修改的是副本，不影响原数据。

2. 自动(通过配置文件)

Redis 支持通过在 redis.conf 文件中配置 save 选项，让服务器每隔一段时间自动执行一次 BGSAVE 命令。save 选项可以设置多个保存条件，只要其中任意一个条件被满足，服务器就会执行 BGSAVE 命令。

【示例】redis.conf 中自动保存配置

# 900 秒内，至少对数据库进行了 1 次修改
save 900 1
# 300 秒内，至少对数据库进行了 10 次修改
save 300 10
# 60 秒内，至少对数据库进行了 10000 次修改
save 60 10000

只要满足以上任意条件，Redis 服务就会执行 BGSAVE 命令。

RDB 优缺点

优点

重启后加载快, 相比 AOF 命令执行式恢复, RDB本质就是压缩过的二进制文件,只需要将其全部读入内存即可.
相比 AOF RDB空间利用率更高.

缺点

备份频率较低,每次只能全量备份,如果在备份开始前发生故障,会导致丢失大量数据,无法满足强一致性.
备份时间长,如果数据量很大，保存快照的时间会很长.

AOF（Append Only File）

AOF 是 Redis 的另一种持久化机制，它通过记录服务器接收到的每一个写命令，以日志形式追加到文件末尾。在 Redis 重启时，通过重新执行 AOF 文件中的命令来恢复数据。AOF 文件是可读的文本格式，通常用于对数据安全性要求较高的场景。

执行方式

1. 手动

开启 AOF：默认关闭，需在 redis.conf 中设置 appendonly yes。
重写 AOF：执行 BGREWRITEAOF 命令，Redis 会 fork 一个子进程，根据当前数据库状态生成一个更紧凑的新 AOF 文件（利用 Copy-On-Write 机制，不阻塞主线程）。

2. 自动（通过配置文件）

AOF 的同步策略由 appendfsync 配置项控制，决定写命令何时从缓冲区刷入磁盘：

# 每次写操作都同步到磁盘（最安全，性能最差）
appendfsync always

# 每秒同步一次（默认推荐，平衡安全与性能）
appendfsync everysec

# 由操作系统决定何时同步（性能最好，但可能丢失较多数据）
appendfsync no

此外，AOF 重写也可自动触发，通过以下配置：

# 当 AOF 文件大小超过上一次重写后大小的指定百分比时，自动触发重写
auto-aof-rewrite-percentage 100
# AOF 文件至少达到指定大小（字节）才触发自动重写
auto-aof-rewrite-min-size 64mb

AOF 优缺点

优点

数据更安全：everysec 模式下最多丢失 1 秒数据，always 模式可做到几乎零丢失。
可读可编辑：AOF 是纯文本格式，若误操作（如误删 key），可手动修改文件删除对应命令后恢复。
自动压缩：通过重写机制，可将冗余命令（如多次 INCR）合并为一条 SET，减小文件体积。

缺点

文件体积大：相比 RDB，AOF 通常更大（尽管重写可优化）。
恢复速度慢：需逐条重放命令，大数据集下恢复时间远长于 RDB。
性能开销：尤其在 always 模式下，每次写操作都需同步磁盘，影响吞吐量。

Redis 数据结构

Thu, 16 Oct 2025 00:00:00 +0000

SDS

`O(1)` 获取长度

SDS 在len属性保存了 SDS的长度所以无需遍历即可获得当前长度
C 字符串不记录自身的长度信息，为获取字符串的长度，必须遍历整个字符串，直到遇到代表字符串结尾的空字符为止， O(N) .

杜绝缓冲区溢出

SDS 通过 len 记录长度和自动扩容机制在修改时保证了当前有足够的缓冲区.
C 字符串不检查空间而且仅通过 \0 判断结尾

空间预分配 & 惰性空间

空间预分配: 当需要进行空间扩容时不仅会分配必要的空间还会分配额外的空间.
惰性空间: 当SDS 缩短保存字符串时程序不立即重新分配缩短后的字节,而是用 free 记录,等待之后使用.

特性	C 字符串	SDS（Simple Dynamic String）
获取字符串长度的时间复杂度	O(N)必须遍历整个字符串直到遇到 `\0`	O(1)长度直接存储在 `len` 字段中，API 自动维护
缓冲区溢出风险	高操作函数（如 `strcat`）不检查目标缓冲区大小，易越界写入	无所有修改 API（如 `sdscat`）先检查空间，自动扩容后再操作
内存重分配频率	每次修改都需重分配增长需 `realloc` 防溢出，缩减需 `realloc` 防内存泄漏	大幅减少通过空间预分配（增长时多分配）和惰性空间释放（缩短时不立即释放）优化，避免频繁 `malloc/realloc`
二进制安全性	不安全字符串中间不能含 `\0`，否则被截断；仅适合文本	安全可存储任意字节（包括 `\0`），数据原样存取，支持图片、音频等二进制数据

SDS 的结构（简化）：

struct sdshdr {
	int len; // 已使用字节数（字符串长度）
	int free;// 未使用字节数
	char buf[];// 实际字符存储区（以 \0 结尾，但内容可含 \0）
}

链表

特点

实现为 双端无环链表。
支持多态（通过 dup/free/match 函数指针）。
用于：List 键、客户端列表、慢查询、发布订阅等。

结构

typedef struct listNode {
    struct listNode *prev, *next;
    void *value;
} listNode;

typedef struct list {
    listNode *head, *tail;
    unsigned long len;
    void *(*dup)(void *ptr);
    void (*free)(void *ptr);
    int (*match)(void *ptr, void *key);
} list;

字典

底层结构

Redis 字典由 两个哈希表（ht[0] 和 ht[1]）组成：

typedef struct dict {
    dictht ht[2];       // ht[0]: 主表；ht[1]: rehash 时的新表
    int rehashidx;      // rehash 进度，-1 表示未进行
} dict;

每个哈希表（dictht）是一个 数组 + 单向链表：
- 数组元素为桶（bucket）；
- 桶内冲突通过 链地址法（单向链表）解决；
- 节点类型为 dictEntry，含 key、value 和 next 指针。

扩容与缩容机制

1. 触发条件（基于负载因子）

负载因子 = ht[0].used / ht[0].size

场景	触发 rehash 条件
无 BGSAVE / BGREWRITEAOF	负载因子 ≥ 1 → 扩容
有 BGSAVE / BGREWRITEAOF	负载因子 ≥ 5 → 才扩容（避免 fork 内存翻倍）
缩容	负载因子 < 0.1 且表足够大

2. 扩容过程（渐进式 rehash）

分配 ht[1]：
- 扩容：size = 第一个 ≥ ht[0].used * 2 的 2 的幂
- 缩容：size = 第一个 ≥ ht[0].used 的 2 的幂
设置 rehashidx = 0，开始 rehash。
每次字典操作（GET/SET/DEL）时：
- 顺带迁移 ht[0][rehashidx] 整个桶 到 ht[1]；
- rehashidx++；
- 新增操作只写入 ht[1]；
- 查找/删除需查两个表（因数据分散在两表中）。
迁移完成：
- 释放 ht[0]；
- ht[1] → ht[0]；
- rehashidx = -1。

三、关键特点与代价

优点

无阻塞：rehash 分摊到每次操作，主线程不卡顿；
数据安全：双表共存期间，读写正确；
自动适应：根据负载动态扩缩容。

缺点

内存占用翻倍：rehash 期间 ht[0] 和 ht[1] 同时存在；
冷数据 rehash 延迟：长期无访问的字典可能迟迟无法完成 rehash；
- Redis 通过 serverCron 定时任务主动推进缓解此问题。

跳表

底层结构

跳表本质上就是多层级链表,不同层级保存着随机跨度的后驱节点的指针,用来快速查找.

节点:

typedef struct zskiplistNode {
//Zset 对象的元素值
	sds ele;
	//元素权重值,用于排序
	double score;
	//后向指针
	struct zskiplistNode *backward;
	//节点的level数组，保存每层上的前向指针和跨度
	struct zskiplistLevel {
		struct zskiplistNode *forward;
		//跨度
		unsigned long span;
	} level[];
} zskiplistNode;

顶层结构:

typedef struct zskiplist {
    struct zskiplistNode *header, *tail;  // 头尾指针（O(1) 访问）
    unsigned long length;                 // 节点总数（O(1) 获取长度）
    int level;                            // 当前跳表最大层数（不含头节点）
} zskiplist;

header 是一个 特殊的头节点，不存实际数据（ele = NULL, score = 0），但有完整的 level[] 数组（如 32 层或 64 层）。
tail 指向最后一个真实数据节点（用于 ZREVRANGE 等反向操作）。
level 是 所有数据节点中的最大层数（头节点层数不计入）。

创建过程

Redis在创建头节点时如果层高最大限制是 32，那么在创建跳表「头节点」的时候，就会直接创建 32 层高的头节点. 在创建新节点时会在 [0, 1] 随机取值,如果小于 0.25 则会增加层高,继续取值,直到值大于 0.25.

Redis为什么使用跳表而不是用B+树?

Redis 是内存数据库，跳表在实现简单性、写入性能、内存访问模式等方面的综合优势，使其成为更合适的选择。


维度	跳表优势	B+ 树劣势
内存访问	符合CPU缓存局部性，指针跳转更高效	节点结构复杂，缓存不友好
实现复杂度	代码简洁，无复杂平衡操作	节点分裂/合并逻辑复杂，代码量大
写入性能	插入/删除仅需调整局部指针	插入可能触发递归节点分裂，成本高
内存占用	结构紧凑，无内部碎片	节点预分配可能浪费内存

Redis 选择使用跳表（Skip List）而不是 B+ 树来实现有序集合（Sorted Set）等数据结构，是经过多方面权衡后的结果。以下是详细的原因分析：

1、内存结构与访问模式的差异

B+ 树的特性

磁盘友好：B+ 树的设计目标是优化磁盘I/O，通过减少树的高度来降低磁盘寻道次数（例如，一个3层的B+树可以管理数百万数据）。
节点填充率高：每个节点存储多个键值（Page/Block），适合批量读写。
范围查询高效：叶子节点形成有序链表，范围查询（如 ZRANGE）性能极佳。

跳表的特性

内存友好：跳表基于链表，通过多级索引加速查询，内存访问模式更符合CPU缓存局部性（指针跳跃更少）。
简单灵活：插入/删除时仅需调整局部指针，无需复杂的节点分裂与合并。
概率平衡：通过随机层高实现近似平衡，避免了严格的平衡约束（如红黑树的旋转）。

Redis 是内存数据库，数据完全存储在内存中，不需要优化磁盘I/O，因此 B+ 树的磁盘友好特性对 Redis 意义不大。而跳表的内存访问模式更优，更适合高频的内存操作。

2、实现复杂度的对比

B+ 树的实现复杂度：

节点分裂与合并：插入/删除时可能触发节点分裂或合并，需要复杂的再平衡逻辑。
锁竞争：在并发环境下，B+ 树的锁粒度较粗（如页锁），容易成为性能瓶颈。
代码复杂度：B+ 树的实现需要处理大量边界条件（如最小填充因子、兄弟节点借用等）。

跳表的实现复杂度：

无再平衡操作：插入时只需随机生成层高，删除时直接移除节点并调整指针。
细粒度锁或无锁：跳表可以通过分段锁或无锁结构（如 CAS）实现高效并发。
代码简洁：Redis 的跳表核心代码仅需约 200 行（B+ 树实现通常需要数千行）。

对于 Redis 这种追求高性能和代码简洁性的项目，跳表的低实现复杂度更具吸引力，Redis作者Antirez曾表示，跳表的实现复杂度远低于平衡树，且性能相近，是更优选择。

3、性能对比

查询性能

单点查询：跳表和 B+ 树的时间复杂度均为 O(log N)，但跳表的实际常数更小（内存中指针跳转比磁盘块访问快得多）。
范围查询：B+ 树的叶子链表在范围查询时占优，但跳表通过双向链表也能高效支持 ZRANGE 操作。

写入性能

B+ 树：插入可能触发节点分裂，涉及父节点递归更新，成本较高。
跳表：插入仅需修改相邻节点的指针，写入性能更优（Redis 的 ZADD 操作时间复杂度为 O(log N)）。

实测数据：在内存中，跳表的插入速度比 B+ 树快 2-3 倍，查询速度相当。

4、内存占用

B+ 树：每个节点需要存储多个键值和子节点指针，存在内部碎片（节点未填满时）。
跳表：每个节点只需存储键值、层高和多个前向指针，内存占用更紧凑。

压缩列表是怎么实现的？

压缩列表是 Redis 为了节约内存而开发的，它是由连续内存块组成的顺序型数据结构，有点类似于数组。

压缩列表在表头有三个字段：

zlbytes，记录整个压缩列表占用对内存字节数；
zltail，记录压缩列表「尾部」节点距离起始地址由多少字节，也就是列表尾的偏移量；
zllen，记录压缩列表包含的节点数量；
zlend，标记压缩列表的结束点，固定值 0xFF（十进制255）。

在压缩列表中，如果我们要查找定位首尾元素通过表头三个字段（zllen）的长度直接定位，复杂度是 O(1)。查找其他元素时，只能逐个查找O(N) ，因此压缩列表不适合保存过多的元素。

另外，压缩列表节点（entry）的构成如下：

压缩列表节点包含三部分内容：

prevlen，记录了「前一个节点」的长度，目的是为了实现从后向前遍历；
encoding，记录了当前节点实际数据的「类型和长度」，类型主要有两种：字符串和整数。
data，记录了当前节点的实际数据，类型和长度都由 encoding 决定；

往压缩列表中插入数据时，压缩列表就会根据数据类型是字符串还是整数，以及数据的大小，会使用不同空间大小的 prevlen 和 encoding 这两个元素里保存的信息，这种根据数据大小和类型进行不同的空间大小分配的设计思想，正是 Redis 为了节省内存而采用的。

压缩列表的缺点是会发生连锁更新的问题，因此连锁更新一旦发生，就会导致压缩列表占用的内存空间要多次重新分配，这就会直接影响到压缩列表的访问性能。

所以说，虽然压缩列表紧凑型的内存布局能节省内存开销，但是如果保存的元素数量增加了，或是元素变大了，会导致内存重新分配，最糟糕的是会有「连锁更新」的问题。

因此，压缩列表只会用于保存的节点数量不多的场景，只要节点数量足够小，即使发生连锁更新，也是能接受的。

虽说如此，Redis 针对压缩列表在设计上的不足，在后来的版本中，新增设计了两种数据结构：quicklist（Redis 3.2 引入）和 listpack（Redis 5.0 引入）。这两种数据结构的设计目标，就是尽可能地保持压缩列表节省内存的优势，同时解决压缩列表的「连锁更新」的问题。

listpack 采用了压缩列表的很多优秀的设计，比如还是用一块连续的内存空间来紧凑地保存数据，并且为了节省内存的开销，listpack 节点会采用不同的编码方式保存不同大小的数据。

我们先看看 listpack 结构：

listpack 头包含两个属性，分别记录了 listpack 总字节数和元素数量，然后 listpack 末尾也有个结尾标识。图中的 listpack entry 就是 listpack 的节点了。

每个 listpack 节点结构如下：

主要包含三个方面内容：

encoding，定义该元素的编码类型，会对不同长度的整数和字符串进行编码；
data，实际存放的数据；
len，encoding+data的总长度；

可以看到，listpack 没有压缩列表中记录前一个节点长度的字段了，listpack 只记录当前节点的长度，当我们向 listpack 加入一个新元素的时候，不会影响其他节点的长度字段的变化，从而避免了压缩列表的连锁更新问题。