Redis 深度剖析：从入门到源码级精通

┌─────────────────────────────────────────────────────────────┐
│  Redis 高性能的核心原因
├─────────────────────────────────────────────────────────────┤
│  1. 纯内存操作    → 纳秒级访问延迟
│  2. 单线程模型    → 避免上下文切换和锁竞争
│  3. IO多路复用    → 单线程处理数万并发连接
│  4. 高效数据结构  → SDS、跳表、压缩列表等优化
│  5. C语言实现     → 接近硬件的性能
└─────────────────────────────────────────────────────────────┘

Redis 4.0 及以前：
┌─────────────────────────────────────┐
│  主线程
│  ├─ 接收连接
│  ├─ 读取请求
│  ├─ 执行命令（单线程）
│  └─ 发送响应
└─────────────────────────────────────┘

Redis 6.0+：
┌─────────────────────────────────────────────────────┐
│  主线程（命令执行）        多个 IO 线程（网络读写）
│  ├─ 执行命令              ├─ 接收连接
│  └─ 命令排队              ├─ 读取请求
│                          └─ 发送响应
└─────────────────────────────────────────────────────┘

// sdshdr8 结构（字符串长度 < 256）
struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len;        // 已使用长度
    uint8_t alloc;      // 分配的总长度
    unsigned char flags; // 类型标识
    char buf[];         // 柔性数组，实际存储数据
};

// sdshdr16 结构（字符串长度 < 65536）
struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len;
    uint16_t alloc;
    unsigned char flags;
    char buf[];
};

SDS 内存布局示例：存储 "Redis"
┌─────────┬─────────┬───────┬─────────────────┐
│  len=5  │ alloc=5 │ flags │  R  e  d  i  s  │
│  1 byte │ 1 byte  │ 1byte │     5 bytes     │
└─────────┴─────────┴───────┴─────────────────┘
         ↑                                     ↑
       头部                                  数据（末尾有 \0，兼容 C 函数）

// 扩容策略源码简化
if (len + addlen < 1MB) {
    // 小于 1MB，翻倍扩容
    newlen = (len + addlen) * 2;
} else {
    // 大于 1MB，只增加 1MB
    newlen = (len + addlen) + 1MB;
}

// 缩短字符串时，不立即释放内存
void sdsclear(sds s) {
    struct sdshdr *sh = (void*)(s - sizeof(struct sdshdr));
    sh->len = 0;           // 长度置 0
    sh->buf[0] = '\0';     // 第一个字符置结束符
    // 注意：alloc 不变，内存不释放！
}

level 3:  head ───────────────────────────────→  NULL
                ↓
level 2:  head ───────────────→ [70] ─────────→  NULL
                ↓                 ↓
level 1:  head ─────→ [30] ───→ [70] ───→ [99] → NULL
                ↓       ↓         ↓         ↓
level 0:  head → [3] → [30] → [55] → [70] → [99] → NULL
                  ↓      ↓       ↓       ↓       ↓
                score=3 score=30 score=55 score=70 score=99

typedef struct zskiplistNode {
    sds ele;                    // 成员对象
    double score;               // 分值
    struct zskiplistNode *backward;  // 后退指针（用于反向遍历）
    struct zskiplistLevel {
        struct zskiplistNode *forward;  // 前进指针
        unsigned int span;       // 跨度（用于计算排名）
    } level[];                  // 柔性数组，层级数组
} zskiplistNode;

typedef struct zskiplist {
    struct zskiplistNode *header, *tail;  // 头尾指针
    unsigned long length;       // 节点数量
    int level;                  // 最大层数
} zskiplist;

// 随机生成层级（概率 0.5，最大 32 层）
int zslRandomLevel(void) {
    int level = 1;
    while ((random() & 0xFFFF) < (ZSKIPLIST_P * 0xFFFF))
        level += 1;
    return (level < ZSKIPLIST_MAXLEVEL) ? level : ZSKIPLIST_MAXLEVEL;
}
// 期望层级：1 + 0.5 + 0.25 + ... ≈ 2

typedef struct dictEntry {
    void *key;                  // 键
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;                        // 值
    struct dictEntry *next;     // 拉链法解决冲突
} dictEntry;

typedef struct dictht {
    dictEntry **table;          // 哈希表数组
    unsigned long size;         // 表大小（2^n）
    unsigned long sizemask;     // 掩码 = size - 1
    unsigned long used;         // 已有节点数
} dictht;

typedef struct dict {
    dictType *type;             // 类型特定函数
    void *privdata;             // 私有数据
    dictht ht[2];               // 两个哈希表，rehash 时使用
    long rehashidx;             // rehash 进度，-1 表示未在进行
    unsigned long iterators;    // 正在运行的迭代器数量
} dict;

Rehash 前：
ht[0]: size=4, used=4    ht[1]: size=0, used=0
┌───┬───┬───┬───┐
│ 0 │ 1 │ 2 │ 3 │
└─┬─┴─┬─┴─┬─┴─┬─┘
  A   B   C   D

Rehash 中（rehashidx=1）：
ht[0]: size=4, used=3    ht[1]: size=8, used=1
┌───┬───┬───┬───┐        ┌───┬───┬───┬───┬───┬───┬───┬───┐
│ X │ X │ 2 │ 3 │        │ 0 │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │
└───┴───┴─┬─┴─┬─┘        └─┬─┴───┴───┴───┴───┴───┴───┴───┘
          C   D            A
          ↑ rehashidx=1
          B 已迁移

Rehash 后：
ht[0]: size=0, used=0    ht[1]: size=8, used=4
                         ┌───┬───┬───┬───┬───┬───┬───┬───┐
                         │ 0 │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │
                         └─┬─┴─┬─┴─┬─┴─┬─┴───┴───┴───┴───┘
                           A   B   C   D

// 使用 MurmurHash2 算法计算 hash 值
uint64_t dictGenHashFunction(const void *key, int len) {
    return MurmurHash2_64(key, len, dict_hash_function_seed);
}

// 冲突解决：头插法拉链
// 新节点插入链表头部（O(1)）

<zlbytes> <zltail> <zllen> <entry> <entry> ... <entry> <zlend>
  4字节    4字节    2字节   变长     变长        变长    1字节

entry 结构：
<prevlen> <encoding> <content>
  变长      变长       变长

typedef struct quicklist {
    quicklistNode *head;        // 头节点
    quicklistNode *tail;        // 尾节点
    unsigned long count;        // 总元素数
    unsigned long len;          // 节点数
    int fill : 16;              // 单个 ziplist 大小限制
    unsigned int compress : 16; // 两端不压缩的节点数
} quicklist;

typedef struct quicklistNode {
    struct quicklistNode *prev;
    struct quicklistNode *next;
    unsigned char *zl;          // 指向 ziplist 或 listpack
    unsigned int sz;            // ziplist 大小
    unsigned int count : 16;    // 元素数量
    unsigned int encoding : 2;  // RAW==1 or LZF==2
    unsigned int container : 2; // NONE==1 or ZIPLIST==2 or LISTPACK==3
    unsigned int recompress : 1; // 是否被解压过
    unsigned int attempted_compress : 1;
    unsigned int extra : 10;
} quicklistNode;

quicklist 结构示意：
┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│  Node 1 │ ↔  │  Node 2 │ ↔  │  Node 3 │ ↔  │  Node 4 │
│ (ziplist)│    │ (ziplist)│    │ (ziplist)│    │ (ziplist)│
│ 2 items │    │ 2 items │    │ 2 items │    │ 1 item  │
└─────────┘    └─────────┘    └─────────┘    └─────────┘
    ↑                                              ↑
  head（热数据，不压缩）                        tail（热数据，不压缩）

中间节点可以使用 LZF 压缩节省内存

listpack 结构：
<total-bytes> <num-elements> <element> ... <element> <end-marker>
   4字节         2字节       变长            变长       1字节(0xFF)

element 结构：
<encoding-type> <element-data> <element-tot-len>
    变长           变长            变长（逆向遍历用）

1. 执行 BGSAVE
        ↓
2. Redis fork() 子进程（Copy-on-Write）
   ┌─────────────────┬─────────────────┐
   │    父进程        │     子进程       │
   │  继续处理请求     │   生成 RDB 文件  │
   │  写时复制修改页   │   读取内存快照   │
   └─────────────────┴─────────────────┘
        ↓
3. 子进程完成 RDB 写入临时文件
        ↓
4. 原子替换旧 RDB 文件

fork() 时刻：
父进程内存页: [A][B][C][D]
                   ↓ fork
子进程内存页: [A][B][C][D]  （共享同一物理内存，引用计数+1）

父进程写入页 B 时：
父进程: [A][B'][C][D]  （B' 是新分配的页）
子进程: [A][B][C][D]   （仍然读取原来的 B）

写操作越频繁，COW 开销越大

┌─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐
│  "REDIS"    │  RDB_VERSION│  SELECT_DB  │  KEY_VALUE  │   EOF       │
│   5字节      │   4字节      │   变长      │    pairs    │  8字节校验和  │
└─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘

KEY_VALUE 对编码：
- 过期时间（可选）
- 值类型（1字节）
- 键（长度编码 + 内容）
- 值（根据类型编码）

原 AOF 文件（多次修改同一 key）：
SET counter 0
INCR counter
INCR counter
INCR counter
...（10000 次 INCR）

重写后（只保留最终结果）：
SET counter 10000

重写流程：
1. fork 子进程
2. 子进程遍历当前内存数据，写入新 AOF
3. 父进程继续处理请求，同时将新命令写入 AOF 缓冲区和重写缓冲区
4. 子进程完成后，父进程将重写缓冲区的数据追加到新 AOF
5. 原子替换旧 AOF

// 重写时，直接读取内存中的键值对
int rewriteAppendOnlyFile(char *filename) {
    // 遍历所有数据库
    for (j = 0; j < server.dbnum; j++) {
        // 遍历数据库中的所有键
        while((de = dictNext(di)) != NULL) {
            keystr = dictGetKey(de);
            o = dictGetVal(de);

            // 根据类型写入对应的命令
            if (o->type == OBJ_STRING) {
                // 写入 SET 命令
                rewriteStringObject(f, key, o);
            } else if (o->type == OBJ_LIST) {
                // 写入 RPUSH 命令序列
                rewriteListObject(f, key, o);
            }
            // ... 其他类型
        }
    }
}

混合 AOF 文件结构：
┌─────────────────┬─────────────────┐
│   RDB 格式头部   │   AOF 格式增量   │
│  （全量数据）     │  （重写后的命令） │
└─────────────────┴─────────────────┘

优势：
- 结合了 RDB 的快速恢复和 AOF 的完整性
- 重写时先写 RDB 格式，后续命令以 AOF 格式追加

┌─────────┐         ┌─────────┐         ┌─────────┐
│ Master  │ ──────→ │ Slave 1 │         │ Slave 2 │
│  写+读   │         │   读    │         │   读    │
└─────────┘         └─────────┘         └─────────┘
     ↓
┌─────────┐
│ Slave 3 │
│   读    │
└─────────┘

1. 建立连接
Slave ───── SYNC/PSYNC ─────→ Master

2. 全量同步（首次或复制偏移量太旧）
Master ───── RDB 文件 ─────→ Slave
Master ───── 缓冲区命令 ───→ Slave

3. 增量同步（复制偏移量在缓冲区范围内）
Master ───── 缺失的命令 ───→ Slave

4. 持续复制
Master 每执行一个写命令，异步发送给所有 Slave

// 部分重同步条件：
// 1. Master 的复制 ID 匹配
// 2. 请求的复制偏移量在 Master 的复制积压缓冲区中

// 复制积压缓冲区（replication backlog）
// 固定大小（默认 1MB），循环缓冲区
// 存储最近传播的写命令

┌─────────┐    ┌─────────┐    ┌─────────┐
│Sentinel1│───→│Sentinel2│←───│Sentinel3│
│  (投票)  │    │  (投票)  │    │  (投票)  │
└────┬────┘    └────┬────┘    └────┬────┘
     └──────────────┼──────────────┘
                    ↓
              ┌─────────┐
              │  Master │ ←── 监控
              └────┬────┘
                   │
         ┌─────────┼─────────┐
         ↓         ↓         ↓
    ┌─────────┐ ┌─────────┐ ┌─────────┐
    │ Slave 1 │ │ Slave 2 │ │ Slave 3 │ ←── 监控
    └─────────┘ └─────────┘ └─────────┘

1. 主观下线（SDOWN）
   单个 Sentinel 认为 Master 不可用（超过 down-after-milliseconds）

2. 客观下线（ODOWN）
   足够多的 Sentinel 同意 Master 不可用（达到 quorum）

3. 选举 Leader Sentinel
   使用 Raft 算法在 Sentinel 之间选举领导者

4. 选择新 Master
   - 过滤掉不健康的 Slave
   - 选择优先级最高的（replica-priority）
   - 选择复制偏移量最大的（数据最新）
   - 选择 Run ID 最小的

5. 提升新 Master
   SLAVEOF NO ONE

6. 重新配置其他 Slave
   SLAVEOF new_master_ip new_master_port

7. 更新配置
   将旧 Master 标记为 Slave（恢复后自动同步）

         ┌─────────┐
         │ Client  │
         └────┬────┘
              │
    ┌─────────┼─────────┐
    ↓         ↓         ↓
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Master A│ │ Master B│ │ Master C│  (16384 个槽位)
│ (0-5460)│ │(5461-10922)│(10923-16383)│
└────┬────┘ └────┬────┘ └────┬────┘
     ↓          ↓          ↓
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Slave A1│ │ Slave B1│ │ Slave C1│
└─────────┘ └─────────┘ └─────────┘

CRC16(key) % 16384 = slot

示例：
"user:1000" → CRC16 → 12345 % 16384 = 12345 → 属于 Master C
"user:1001" → CRC16 → 5000 % 16384 = 5000 → 属于 Master B

场景 1：槽位已迁移（MOVED）
Client ── GET key ──→ Node A
Node A ── MOVED 12345 192.168.1.12:6379 ──→ Client
Client ── 更新槽位映射 ──→ 重试请求 Node B

场景 2：槽位正在迁移（ASK）
Client ── GET key ──→ Node A
Node A ── ASKING ──→ Client （提示去目标节点试试）
Client ── ASKING + GET key ──→ Node B

# Python 示例：Pipeline 批量操作
import redis

r = redis.Redis()
pipe = r.pipeline()

# 批量写入
for i in range(10000):
    pipe.set(f"key:{i}", f"value:{i}")

# 一次发送所有命令
pipe.execute()

# 对比：逐个发送需要 10000 次网络往返
# Pipeline 只需要 1 次（或几次，如果命令太多）

-- 实现原子扣减库存
local stock = redis.call('GET', KEYS[1])
if tonumber(stock) > 0 then
    redis.call('DECR', KEYS[1])
    return 1  -- 扣减成功
else
    return 0  -- 库存不足
end

-- 调用
-- EVAL "脚本内容" 1 stock:1001

读操作：
1. 先读 Cache
2. Cache 未命中，读 Database
3. 将数据写入 Cache

写操作：
1. 先写 Database
2. 再删 Cache（不是更新 Cache）

为什么删除而不是更新？
- 并发场景下，更新可能导致脏数据
- 懒加载思想，下次读时再加载

缓存穿透：查询不存在的数据（绕过缓存直达 DB）
解决：布隆过滤器、缓存空值

缓存击穿：热点 key 过期，大量请求打到 DB
解决：互斥锁、逻辑过期、热点 key 永不过期

缓存雪崩：大量 key 同时过期
解决：随机过期时间、多级缓存、熔断降级

// 事件循环主流程
void aeMain(aeEventLoop *eventLoop) {
    eventLoop->stop = 0;
    while (!eventLoop->stop) {
        // 1. 处理 beforesleep 回调
        if (eventLoop->beforesleep != NULL)
            eventLoop->beforesleep(eventLoop);

        // 2. 多路复用等待事件
        aeProcessEvents(eventLoop, AE_ALL_EVENTS|AE_CALL_AFTER_SLEEP);
    }
}

// aeProcessEvents 核心逻辑
int aeProcessEvents(aeEventLoop *eventLoop, int flags) {
    // 1. 计算最近的定时器事件
    shortest = aeSearchNearestTimer(eventLoop);

    // 2. 调用多路复用 API（epoll/kqueue/select）
    numevents = aeApiPoll(eventLoop, tvp);

    // 3. 处理文件事件（可读/可写）
    for (j = 0; j < numevents; j++) {
        aeFileEvent *fe = &eventLoop->events[eventLoop->fired[j].fd];
        // 调用读/写回调函数
    }

    // 4. 处理时间事件（定时器）
    processTimeEvents(eventLoop);
}

Client 发送: SET key value
                    ↓
            读取到 querybuf
                    ↓
            使用 RESP 协议解析
                    ↓
            查找命令表 (lookupCommand)
                    ↓
            执行权限检查
                    ↓
            调用命令处理函数 (call)
                    ↓
            写回响应到 client buf
                    ↓
            添加到 write 队列
                    ↓
            事件循环发送响应

struct redisCommand {
    char *name;                     // 命令名
    redisCommandProc *proc;         // 处理函数
    int arity;                      // 参数个数
    char *sflags;                   // 字符串标志
    uint64_t flags;                 // 实际标志位
    redisGetKeysProc *getkeys_proc;
    int firstkey, lastkey, keystep;
    long long microseconds;         // 执行时间统计
    long long calls;                // 调用次数统计
    int id;                         // 命令 ID
};

// 命令标志
#define CMD_READONLY 1      // 只读命令
#define CMD_WRITE 2         // 写命令
#define CMD_DENYOOM 4       // 可能使内存超限
#define CMD_FAST 8          // 快速命令（O(1)）

简单字符串：+OK\r\n
错误：-ERR unknown command\r\n
整数：:1000\r\n
批量字符串：$6\r\nfoobar\r\n  （$后面是长度）
数组：*2\r\n$3\r\nGET\r\n$3\r\nkey\r\n

示例：SET mykey myvalue
*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n

-- 秒杀扣减库存脚本（原子执行）
local stock = tonumber(redis.call('GET', KEYS[1]))
if stock == nil then
    return -1  -- 商品不存在
end
if stock <= 0 then
    return 0   -- 已售罄
end
if stock < tonumber(ARGV[1]) then
    return -2  -- 库存不足
end
redis.call('DECRBY', KEYS[1], ARGV[1])
return 1       -- 扣减成功

apiVersion: databases.spotahome.com/v1
kind: RedisFailover
metadata:
  name: redis-cluster
spec:
  sentinel:
    replicas: 3
  redis:
    replicas: 3
    resources:
      requests:
        cpu: 100m
        memory: 256Mi
      limits:
        cpu: 400m
        memory: 512Mi

Level 1: 基础使用
├── 5 大数据类型的基本操作
├── 持久化配置与选择
└── 简单的缓存应用

Level 2: 进阶使用
├── 主从复制与高可用架构
├── Lua 脚本与事务
├── 性能优化与问题排查
└── 缓存设计模式

Level 3: 深入理解
├── 底层数据结构实现
├── 源码阅读（事件循环、命令执行）
├── 网络协议与通信模型
└── 分布式算法（Raft、Gossip）

Level 4: 生产实战
├── 大规模集群运维
├── 自定义模块开发
├── 内核优化与调优
└── 贡献开源社区