数据结构|源码解析|Redis环形链表详解与实现机制分析，redis 环形链表

🔍 Redis环形链表详解：源码解析与实现机制大揭秘

📢 最新动态（2025年7月）
Redis 7.4版本近期优化了内存碎片处理机制，对环形链表（quicklist）的节点合并策略进行了微调，进一步提升了存储效率！🎉

什么是Redis环形链表？

Redis的环形链表并不是传统意义上的循环链表，而是通过quicklist（快速链表）结构实现的双向链表+压缩列表（ziplist）的混合体，它的核心特点是：

• 分段存储：大链表拆分为多个ziplist节点，减少内存碎片
• 双向访问：支持从头/尾高效操作（LPUSH/RPUSH等）
• 自动压缩：节点超过阈值时会启用LZF压缩算法

💡 设计哲学：在内存效率和操作速度之间找平衡！

核心源码解析（基于Redis 7.4）

🔧 数据结构定义

// quicklist节点  
typedef struct quicklistNode {  
    struct quicklistNode *prev;  // 前驱指针  
    struct quicklistNode *next;  // 后继指针  
    unsigned char *zl;           // 指向ziplist的指针  
    size_t sz;                   // ziplist字节大小  
    unsigned int count : 16;     // ziplist元素计数  
    unsigned int encoding : 2;   // 编码方式（RAW/LZF）  
    // ...其他字段省略  
} quicklistNode;  
// 快速链表本体  
typedef struct quicklist {  
    quicklistNode *head;  
    quicklistNode *tail;  
    unsigned long count;        // 所有ziplist元素总数  
    unsigned long len;          // quicklist节点数  
    int fill : 16;              // ziplist大小限制（由list-max-ziplist-size配置）  
    unsigned int compress : 16; // 压缩深度（由list-compress-depth配置）  
} quicklist;  

🛠️ 关键操作逻辑

插入元素（LPUSH为例）

1. 检查头节点是否有空间（根据fill参数判断）
2. 如果空间不足,创建新quicklistNode并插入到头部
3. 调用ziplistPush向ziplist写入数据

压缩机制

当配置list-compress-depth为2时：

• 链表的首尾各2个节点保持不压缩
• 中间节点超过阈值则启用LZF压缩

为什么这样设计？

🎯 性能权衡的艺术

🌰 实际场景示例

执行LPUSH mylist 1000个元素时：

1. 前32个元素存入第一个ziplist（假设fill=32）
2. 第33个元素触发新建节点
3. 最终形成约32节点的quicklist

调优建议

# redis.conf关键参数  
list-max-ziplist-size 32    # 每个ziplist最多元素数  
list-compress-depth 1       # 首尾1个节点不压缩  

• 高写入场景：增大ziplist-size减少节点数
• 内存敏感场景：调低compress-depth增加压缩比例

环形？其实是“逻辑闭环”

虽然名称叫“环形”，但实际是通过头尾指针相连实现逻辑闭环：

quicklist->tail->next = NULL;  // 非物理环形！  
quicklist->head->prev = NULL;  

这种设计让LRANGE等操作无需检查边界条件，提升遍历效率。

🚀 总结
Redis的环形链表（quicklist）通过“链表套压缩列表”的巧思，实现了：
✔️ 低内存碎片
✔️ O(1)头尾操作
✔️ 自适应压缩

下次使用LPOP命令时，不妨想想背后这个精妙的“俄罗斯套娃”结构！ 🪆