多线程redis项目基石

目录

前提：redis项目之存储类型

一、redis源码如何做的

二、获取当前时间

三、掌握容器的查找

四、关于redis的过期策略

3.1 惰性删除

3.2 定期删除

五、关于redis的持久化策略

5.1 rdb生成快照

5.2 aof

六、跳表

---

前提：redis项目之存储类型

b站仙可程序员的总结

一、redis源码如何做的

typedef struct dict {
    dictType *type;      // 函数指针表：哈希函数、键对比函数等
    void *privdata;      // 私有数据：传给 type 里的函数
    dictht ht[2];        // 【核心】两个哈希表！ht[0] 是主表，ht[1] 是 rehash 临时表
    long rehashidx;      // rehash 进度：-1 表示没在 rehash，≥0 表示当前 rehash 到的桶索引
    unsigned long iterators; // 安全迭代器数量
} dict;

typedef struct dictht {
    dictEntry **table;   // 哈希桶数组：每个元素是指向 dictEntry 的指针
    unsigned long size;  // 桶数组的大小（必须是 2^n）
    unsigned long sizemask; // 桶数组的掩码：size-1（用于快速计算哈希值对应的桶索引）
    unsigned long used;  // 已存储的键值对数量
} dictht;

typedef struct dictEntry {
    void *key;           // 键（通常是 SDS）
    union {              // 【核心】值用 union 节省内存
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next; // 指向下一个节点（链地址法处理哈希冲突）
} dictEntry;

//注意dictEntry中的联合体中的val实际指向一个redisObject（里面存储实际value）
typedef struct redisObject {
    unsigned type:4;        // 【核心标记】4位，标记 Value 的类型
    unsigned encoding:4;    // 4位，标记 Value 的底层数据结构
    unsigned lru:LRU_BITS;  // LRU 时间（用于内存淘汰）
    int refcount;            // 引用计数（用于对象共享）
    void *ptr;               // 指向实际的底层数据结构
} robj;

一句话说清楚：采用了链地址法，hash桶，每个桶都是一条链子，避免了hash冲突

dict里面有两个hash表，其中一个是为了rehash的，哈希表里面是哈希桶，每个桶存储的是dictEntry*（也就是链头节点），然后每个节点存储的是key-value

1.最核心设计亮点：渐进式 rehash

这是 Redis dict 最经典的设计，解决了 大哈希表扩容时的阻塞问题。

1.1 为什么需要渐进式 rehash？

普通哈希表（比如 std::unordered_map）扩容时是一次性的：

• 当 used > size * load_factor（通常 0.75）时，分配新的桶数组；

• 把所有节点从旧桶数组一次性拷贝到新桶数组；

• 如果哈希表很大（比如 1000 万个键），这一步会阻塞几百毫秒甚至几秒，Redis 作为实时数据库绝对不能接受。

1.2 Redis 的解决方案：渐进式 rehash

核心思路：不一次性拷贝所有节点，而是分多次、逐步拷贝，把扩容开销分摊到每次操作中。

具体步骤

1. 触发扩容：当 ht[0].used > ht[0].size * load_factor 时：

   • 给 ht[1] 分配新的桶数组（大小是 ht[0].size 的 2 倍，且是 2 的幂）；

   • 把 rehashidx 设为 0（表示开始 rehash）。

2. 逐步迁移：每次对 dict 进行增删改查时：

   • 顺便把 ht[0].table[rehashidx] 这个桶里的所有节点从 ht[0] 拷贝到 ht[1]；

   • rehashidx++；

   • 如果 rehashidx 达到 ht[0].size，说明所有节点都迁移完了。

3. 完成迁移：

   • 把 ht[1] 设为 ht[0]；

   • 释放旧的 ht[0]；

   • 把 rehashidx 设为 -1（表示 rehash 结束）。

效果

• 扩容的开销被分摊到每次操作中，单次操作的延迟只有几纳秒，完全不会阻塞；

• 用户感知不到扩容的存在。

---

2. 哈希冲突处理：链地址法

和 std::unordered_map 类似，Redis 用 链地址法 处理哈希冲突：

• 当两个键的哈希值落在同一个桶里时，用链表把它们串起来；

• 查找时，先算哈希值找到桶，再遍历链表对比键。

---

3. 哈希函数和桶大小的选择

3.1 哈希函数

Redis 用 MurmurHash2 哈希函数：

• 计算速度快；

• 哈希值分布均匀，减少哈希冲突；

• 适合字符串、整数等多种类型的键。

3.2 桶大小的选择

• 桶大小必须是 2 的幂；

• 配合 sizemask（size-1）用位运算快速计算桶索引：hash & sizemask；

• 比取模运算（hash % size）快很多。

---

4. Redis dict vs C++ std::unordered_map 核心对比

维度	Redis dict	C++ std::unordered_map
扩容方式	渐进式 rehash（分多次，不阻塞）	一次性扩容（可能阻塞）
桶大小	必须是 2^n（位运算快速计算索引）	通常是质数（取模计算索引）
值存储	用 union 节省内存	直接存储对象（或指针）
迭代器安全性	支持安全迭代器（迭代时不 rehash）	迭代时修改可能导致迭代器失效
内存开销	更小（自研，无 C++ 标准库的额外元数据）	更大（有标准库的额外元数据）
代码复杂度	高（需要自己实现哈希表、渐进式 rehash）	低（直接用标准库）

---

总结

1. 宏观作用：全局哈希表是 Redis KV 存储的核心骨架，所有 Key 都存在这里；

2. 三层结构：dict（管理两个哈希表）→ dictht（实际哈希表）→ dictEntry（哈希节点）；

3. 最核心亮点：渐进式 rehash，解决大哈希表扩容阻塞问题；

4. 哈希冲突处理：链地址法；

5. 性能优化：MurmurHash2 哈希函数、桶大小 2^n、位运算计算索引。

编码的作用：如果所有的key、redisObject、value都分开存，那会造成内存离散，所以编码的作用就是在一些value非常小的情况下，让redisObject和value一块存（也就是开同一块大的内存空间，前面存redisObject，后面存value），这样能够避免内存离散

但是注意不能都开一块，如果value很大，你都开一块了，会造成连续的很大，有时候没有内存分配，内存总量可能还剩很多，但都是 “小块碎片”，没有足够大的连续块；

不是不想都开连续内存，而是大数据下连续内存的 “操作效率、扩容成本、分配成功率” 都太差了，所以 Redis 做了权衡：

• 小数据：连续内存（省内存、Cache 好）；
• 大数据：离散内存（操作快、分配易、扩容灵活）。

这次项目我们主要采用unordered_map实现这个复杂的hash表

维度	Redis dict	std::unordered_map
最大亮点	✅ 渐进式 rehash（不阻塞）	❌ 一次性扩容（可能阻塞）
内存统计	✅ 内置（zmalloc）	❌ 无（需自己封装）
值存储优化	✅ union 节省内存	❌ 无
安全迭代器	✅ 支持	❌ 不支持
哈希函数	✅ MurmurHash2（均匀、快）	⚠️ 取决于标准库
桶大小	✅ 必须 2^n（位运算快）	⚠️ 通常 2^n，但非必须
内存碎片	✅ 少（jemalloc/tcmalloc）	⚠️ 较多（libc malloc）
适用场景	✅ 高性能内存数据库	✅ 通用场景

redis在各个能够优化的地方都做了优化处理

二、获取当前时间

int64_t KeyValueStore::nowMs()
{
  using namespace std::chrono; // 简化 chrono 库的命名空间
  // 核心逻辑：获取当前时间 → 转换为从"纪元"开始的毫秒数 → 返回
  return duration_cast<milliseconds>( // 步骤3：把时间间隔转换成「毫秒」单位
    steady_clock::now()              // 步骤1：获取当前系统的稳定时钟时间点
    .time_since_epoch()              // 步骤2：计算从"纪元时间"到当前时间的总间隔
  ).count();                         // 步骤4：取出毫秒数的数值（转成 int64_t）
}

• steady_clock（稳定时钟）：系统的 “单调递增时钟”，不会因系统时间修改（比如手动调时间、NTP 同步）而跳变，适合计算「时间间隔」；
• time_since_epoch()：计算从 “纪元时间”（不同系统略有差异，通常是 1970-01-01 00:00:00 UTC 或系统启动时间）到当前时间的总时间间隔；
• duration_cast<milliseconds>：把时间间隔强制转换成「毫秒」单位（也可以转成秒 seconds、微秒 microseconds）；
• .count()：取出时间间隔的 “数值部分”（比如 1710000000000 毫秒），返回整数。

steady_clock::now() 返回的不是 “普通数值”，而是 std::chrono::time_point 类型的时间点对象——.time_since_epoch() 是这个对象的成员函数，作用是把 “时间点” 转换成 “从纪元开始的时间间隔”，最终才能换算成毫秒数。

核心就是为了避免有人修改系统时间而导致key的定时删除出现问题

三、掌握容器的查找

find_if

四、关于redis的过期策略

3.1 惰性删除

惰性删除：不主动轮询所有 Key 检查过期，而是在「访问 / 操作 Key 前」先检查是否过期，若过期则直接删除，保证用户获取的永远是未过期的有效数据；

简单来说在get等函数的获取key的时候，先检查一下key是否过期，如果过期直接删除，然后返回nil即可

3.2 定期删除

这是一种主动的删除策略。Redis 会周期性地随机从数据库中取出一定数量的键，检查它们是否过期，并删除其中过期的键。Redis 会通过配置文件中的 hz 参数（默认值是 10 ，表示每秒执行 10 次过期扫描）来控制定期删除操作的执行频率。每次扫描时，Redis 会随机选择一些数据库，然后从每个数据库中随机取出一定数量的键进行检查。这种策略能有效减少过期键对内存的占用 ，不过如果执行过于频繁，会消耗较多 CPU 资源；如果执行频率过低，又会导致过期键长时间占用内存。

五、关于redis的持久化策略

5.1 rdb生成快照

1. 定义

RDB（Redis Database）是一种结构化二进制文件，用于将内存中的 KV 数据序列化后持久化到磁盘，服务重启后可通过加载 RDB 文件恢复数据。

2. 关键澄清：不是 “内存 01 直接拷贝”

对比项	内存直接拷贝（原始二进制）	RDB（结构化二进制）
跨平台性	差（依赖操作系统 / CPU 内存布局）	优（按统一协议序列化）
压缩性	无（直接存内存字节）	有（可对短字符串、整数做编码压缩）
兼容性	差（代码修改后内存布局变化，无法恢复）	优（有版本号，可向前 / 向后兼容）
安全性	差（无校验，数据损坏无法检测）	优（有 CRC64 校验和，可检测数据完整性）

+----------------+----------------+----------------+----------------+----------------+
| 魔数头部       | 版本号         | 数据库数据块    | 结束标记       | 校验和         |
| "MINIREDIS"    | 4字节整数      | 多个 Key-Value  | 1字节(0xFF)    | 8字节CRC64     |
| (8字节)        | (如 0x00000001)| 对（带类型）    |                |                |
+----------------+----------------+----------------+----------------+----------------+

// 单个 Key-Value 数据块结构（以 String 为例）
+------------+------------+------------+------------+------------+
| 数据类型    | Key长度    | Key内容    | Value长度  | Value内容  |
| 1字节       | 变长整数   | 字节流     | 变长整数   | 字节流     |
| (0x00=String)|            |            |            |            |
+------------+------------+------------+------------+------------+

// Hash 数据块结构
+------------+------------+------------+------------+------------+------------+
| 数据类型    | Key长度    | Key内容    | Field数量  | Field1-Value1 | ... |
| 1字节(0x02) | 变长整数   | 字节流     | 4字节整数  | (变长+变长)   | ... |
+------------+------------+------------+------------+------------+------------+

// ZSet 数据块结构（区分 vector/跳表，统一按有序存储）
+------------+------------+------------+------------+------------+------------+
| 数据类型    | Key长度    | Key内容    | 成员数量  | Member1-Score1 | ... |
| 1字节(0x03) | 变长整数   | 字节流     | 4字节整数  | (变长+8字节double) | ... |
+------------+------------+------------+------------+------------+------------+

简单来说就是按照一定的格式，序列化存储起来

5.2 aof

AOF（Append Only File）是 Redis 另一种核心持久化方式，本质是 “追加式写命令日志”—— 和 RDB（快照）不同，AOF 不保存内存数据的副本，而是把每一条写操作命令（如 set/hset/zadd/zrem）按顺序追加到文件末尾；服务重启后，通过重放（Replay） AOF 中的所有写命令来恢复数据，数据安全性比 RDB 更高（可配置秒级持久化）。

维度	AOF（Append Only File）	RDB（Redis Database）
保存内容	写操作命令（如 set key value）	内存数据的结构化快照
保存方式	追加写入（Append）	全量覆盖写入
数据安全性	高（可配置每秒 / 每次写同步）	中（全量快照，可能丢失最后一次快照后的数据）
文件大小	大（记录所有写命令，需重写压缩）	小（结构化二进制，可压缩）
恢复速度	慢（需重放所有命令）	快（直接加载快照）
典型场景	数据安全性要求高（如金融、交易）	备份、快速恢复、数据迁移

Redis 的 AOF 默认使用 RESP（Redis Serialization Protocol） 文本协议记录命令，可读性比 RDB 高（Vim 打开能直接看懂命令）。 

简单来说，采用我们之前写的resp协议进行写进硬盘存储起来

六、跳表

以下是b站仙可程序员的总结

常规链表不便于查找，所以我们在常规链表的基础上增加多级索引，即跳表

决定底层元素能否成为level的索引取决于随机概率p（晋升概率），如果p=0.5，说明每个节点都有一半的机会往上跃迁

注意每一层都有一个头节点

比如查找4，先进入level-2查找，刚好可以则返回

比如查找5，先进入level-2查找，比4大，去下一个节点，即8，因为8比5大，回退上一个节点，然后由节点4进入level-1查找，往右，因为6比5大，所以回退上一个节点，进入node层

然后往右查，5==5，然后返回即可

总结：建立多级索引，达到时间复杂度O(logN)，p 越大，查询越快但内存越高；p 越小，内存越省但查询越慢。

p=0.25 的查询性能和 p=0.5 几乎无感知差异（差 1 倍查询次数，但每次查询都是内存操作，微秒级）。redis选择了0.25

注意p：这里指的是每个节点都有机会往上晋升的概率，真实的跳表（如 Redis）就是通过 “每个节点有 25% 概率晋升一层” 的规则，在概率上实现 “高层节点数≈底层的 1/4”