Redis源码 深入掌握Redis源码解析与实战，redis源码学习指南

🔍 从零开始啃Redis源码：一位程序员的深夜调试实录

"这Redis的QPS怎么突然跌了一半？" 凌晨2点，我盯着监控面板上断崖式下跌的曲线，手边的咖啡已经凉透，这次线上事故最终定位到是哈希表扩容引发的性能抖动——当我真正打开Redis源码时，才发现这个看似简单的内存数据库，藏着太多教科书上没写的实战智慧。

下面是我整理出的Redis源码学习路线,包含那些让我拍案叫绝的设计细节（附关键代码片段解析）。

� 一、先啃硬骨头：Redis的核心数据结构

SDS（简单动态字符串）

为什么Redis不用C原生字符串？ 看sds.h这个结构体就懂了：

struct sdshdr {
    int len;     // 已用长度
    int free;    // 剩余空间
    char buf[];  // 柔性数组
};

精妙之处：

• 🚀 O(1)时间复杂度获取长度（不像strlen()要遍历）
• 💾 空间预分配：追加数据时，SDS会多分配一倍空间（小于1MB时）
• 🔒 二进制安全：通过len字段判断结束，而非\0

字典（dict.c）

Redis的键值对存储核心,渐进式rehash的设计堪称经典：

// 字典结构体关键字段
typedef struct dict {
    dictht ht[2];      // 双哈希表
    int rehashidx;     // rehash进度索引
} dict;

实战技巧：

• 当负载因子 >1 时触发扩容，但不是一次性迁移，而是分摊到每次增删改查操作
• ✨ 写时复制优化：rehash期间同时操作两个哈希表

⚙️ 二、事件循环：单线程为何能扛10万QPS？

ae.c文件中的事件驱动模型是Redis高性能的灵魂：

void aeMain(aeEventLoop *eventLoop) {
    while (!eventLoop->stop) {
        aeProcessEvents(eventLoop, AE_ALL_EVENTS);
    }
}

关键设计：

• � IO多路复用：epoll/kqueue/select的封装
• 🕰️ 时间事件：通过最小堆实现定时任务（如过期键清理）
• 📌 避免阻塞：将耗时操作（RDB持久化）放到子线程执行

有趣的事实：Redis 6.0后引入多线程IO（仅处理网络读写，命令执行仍是单线程）

📦 三、持久化背后的黑科技

RDB快照（rdb.c）

fork()的魔法：

int rdbSave(char *filename) {
    if (fork() == 0) { // 子进程
        saveDataToDisk();  // 写RDB文件
        exit(0);
    }
}

为什么不怕内存翻倍？
得益于Linux的写时复制（COW）机制，父子进程共享内存页，只有被修改的页才会复制

AOF重写（aof.c）

瘦身秘诀：

• 后台线程扫描数据库生成最小命令集
• 重写期间新命令写入AOF缓冲区和重写缓冲区（双保险设计）

🔥 四、源码学习实战建议

1. 调试技巧：

   • 用GDB跟踪processCommand()函数看命令解析全流程
   • 修改redis.conf的loglevel debug观察内部事件

2. 重点文件清单：

   • server.c：服务端主流程
   • t_hash.c：哈希表类型实现
   • evict.c：内存淘汰算法

3. 避坑指南：

   • 别在主线版本（如7.2）直接调试，先用unstable分支
   • 推荐CLion作为源码阅读IDE（比纯vim效率高3倍）

🌟 Redis源码给我的启示

当我终于理解intset（整数集合）如何通过自动升级数据类型来节省内存时，突然明白了一个道理：优秀的系统不是没有妥协，而是把妥协都隐藏在用户看不见的地方。

下次当你用INCR命令时，不妨想想这个计数器背后经过了多少层优化——这或许就是阅读源码最大的乐趣。

（本文代码分析基于Redis 7.2.4版本，2025年7月验证）

💡 小作业：尝试在dict.c中找出哈希表扩容阈值计算公式，评论区等你答案！