源码解析 运行机制红色宝石源码分析三：深入探究redis源码分析三的运行机制

源码解析 | 运行机制红色宝石源码分析三：深入探究Redis源码分析三的运行机制

最新动态： 截至2025年7月，Redis 8.2版本在内存管理和集群通信方面进行了多项优化，这使得我们重新审视其核心运行机制变得更有价值，作为开源社区的"红色宝石"，Redis持续保持着每秒百万级操作的处理能力,而其源码中的精巧设计正是支撑这一性能的关键。

Redis事件循环：单线程为何如此高效？

很多人第一次看Redis源码都会困惑：为什么一个单线程程序能处理这么高的并发？秘密就在src/ae.c这个文件里。

// Redis事件循环核心结构
typedef struct aeEventLoop {
    int maxfd;   /* 当前注册的最大文件描述符 */
    int setsize; /* 最大跟踪的文件描述符数 */
    long long timeEventNextId; // 下一个时间事件ID
    aeFileEvent *events; /* 注册的文件事件数组 */
    aeFiredEvent *fired; /* 已触发的事件数组 */
    aeTimeEvent *timeEventHead; // 时间事件链表头
    // ...其他字段省略
} aeEventLoop;

Redis的事件驱动架构采用了经典的Reactor模式,但有几个特别的设计点：

1. 文件事件处理器：每个客户端连接对应一个文件描述符，Redis使用I/O多路复用技术（epoll/kqueue/select）监听这些描述符

2. 时间事件处理器：处理像过期键清理、统计信息更新等定时任务

3. 优雅的优先级设计：文件事件优先于时间事件，但时间事件不会完全饿死

   

在aeProcessEvents函数中,你会看到这样的处理逻辑：

numevents = aeApiPoll(eventLoop, tvp);
for (j = 0; j < numevents; j++) {
    // 处理文件事件
    fe = &eventLoop->events[eventLoop->fired[j].fd];
    fe->rfileProc()/fe->wfileProc(); // 执行读写回调
}
// 处理时间事件
processed += processTimeEvents(eventLoop);

内存管理：zmalloc的智慧

Redis的src/zmalloc.c展示了内存管理的艺术：

// 内存分配器选择逻辑
#if defined(USE_TCMALLOC)
    #define malloc(size) tc_malloc(size)
    #define realloc(ptr,size) tc_realloc(ptr,size)
    #define free(ptr) tc_free(ptr)
#elif defined(USE_JEMALLOC)
    // ...类似的jemalloc定义
#else
    // 使用系统默认malloc
#endif

特别值得注意的是Redis的内存统计方式：

1. 精确统计：每次分配/释放都会更新used_memory原子变量
2. 内存碎片控制：通过zmalloc_usable_size获取实际分配大小
3. OOM处理：redisOutOfMemoryHandler会在内存不足时选择性拒绝请求

数据结构实现：不只是简单的哈希表

在src/dict.c中,Redis的字典实现有几个精妙之处：

渐进式rehash机制：

// 字典结构中的关键字段
typedef struct dict {
    dictEntry **ht_table[2]; // 两个哈希表
    unsigned long ht_used[2]; // 两个表的计数器
    int rehashidx; // rehash进度，-1表示未进行
    // ...其他字段
} dict;

当需要扩容时，Redis不会一次性迁移所有元素,而是：

1. 分配ht[1]为新大小
2. 设置rehashidx=0开始迁移
3. 每次增删改查操作时迁移一个桶
4. 全部完成后释放ht[0],将ht[1]设为ht[0]

这种设计避免了大规模rehash导致的延迟尖峰。

持久化机制：RDB与AOF的协同

RDB快照生成（src/rdb.c）：

// 关键保存逻辑
int rdbSaveRio(rio *rdb) {
    // 写入魔数"REDIS"
    snprintf(magic,sizeof(magic),"REDIS%04d",RDB_VERSION);
    if (rdbWriteRaw(rdb,magic,9) == -1) return -1;
    // 遍历数据库
    for (j = 0; j < server.dbnum; j++) {
        // 写入每个键值对
        while((de = dictNext(di)) != NULL) {
            robj *key = dictGetKey(de);
            robj *val = dictGetVal(de);
            // 序列化写入
        }
    }
}

AOF重写（src/aof.c）的独特之处在于：

1. 使用子进程进行重写避免阻塞主线程
2. 重写期间的新命令会写入AOF缓冲区和重写缓冲区
3. 完成后用原子操作替换旧文件

集群通信：Gossip协议实现

Redis集群的节点通信实现在src/cluster.c中,有几个关键设计：

1. PING/PONG消息：每个节点随机选择几个其他节点定期通信
2. 故障检测：通过PFAIL/FAIL状态传播识别故障节点
3. 配置纪元：用于解决脑裂情况下的决策冲突

// 集群消息头
typedef struct {
    uint32_t totlen;    // 消息总长度
    uint16_t type;      // 消息类型
    uint16_t count;     // 包含的节点信息数量
    uint64_t currentEpoch;  // 发送方的配置纪元
    // ...其他字段
} clusterMsg;

性能优化技巧：值得学习的编码实践

1. 内联函数：像sdsIncrLen这样的高频操作都使用static inline定义
2. 内存对齐：数据结构会考虑CPU缓存行对齐
3. 分支预测：使用likely/unlikely宏提示编译器优化
4. 零拷贝优化：网络IO尽量使用writev/sendfile

例如处理命令时的高效查找：

// 命令表查找优化
struct redisCommand *lookupCommand(sds name) {
    return dictFetchValue(server.commands, name);
}

Redis源码就像一座精密的钟表，每个齿轮都经过精心设计，通过这次分析，我们不仅能理解Redis高性能背后的原理，更能学到许多可复用的系统编程技巧，建议读者结合最新源码，用gdb实际跟踪几个典型命令的处理流程,会有更直观的体会。