个人真的很喜欢这本书, 从对C语言一窍不通, 到发现C语言竟然如此简洁, 以至于我喜欢上了C! 对此前面的底层数据结构也读了几次, 大致整理了书里的内容, 后面的就粗略看了一下, 不再细细整理了.

Redis的设计与实现(1)-SDS简单动态字符串
Redis的设计与实现(2)-链表
Redis的设计与实现(3)-字典
Redis的设计与实现(4)-跳跃表
Redis的设计与实现(5)-整数集合
Redis的设计与实现(6)-压缩列表

整体的感悟吧, 觉得 Redis 的作者, 对每一块内存非常吝啬, 为了节省内存而制造出各种各样的编码和技巧. 阅读源码的过程中, 也学习到了宏的技巧, 比如说:

#define ZIP_ENTRY_ENCODING(ptr, encoding) do {  \
    (encoding) = (ptr[0]); \
    if ((encoding) < ZIP_STR_MASK) (encoding) &= ZIP_STR_MASK; \
} while(0)

大量的使用 do { ... } while(0) , 上网找过, 说这样写宏展开后就不会编译错误, 当然道理是浅显易懂的. 有些函数, 比如上面的 ZIP_ENTRY_ENCODING , 如果写成真真正正的函数, 会增加函数调用栈的开销, 听说 << C 和指针 >> 这本书会提及, 准备有时间好好看看.

源码的注释版, 真的很好, Redis的代码读起来也还是比较亲切. 工作上, 曾经排查线上 Nginx 的 bug , 准确来说, 应该是 API 网关 kong, 它结合了 OpenResty, 关于 URL 字符串的编码问题, 具体的记不清了, 但里面对字符串的 URL 编码, 用的是查表法和位运算, 这样的转换函数真的是晦涩难懂. 水平真的有限, 我也是请教了同事, 他在 DevCPP 里面逐行调试才知道的.


这本书的后面几部分, 最开始是几个底层数据结构, 然后是对象, 第二部分是单机数据库, 包括 RDB 持久化 和 AOF 持久化, 事件, 客户端和服务端; 第三部分是多机数据库的实现, Redis 集群等, 这一块我还没实践过; 第四部分是比较杂的功能, 包含了发布订阅, 事务, Lua 脚本, 慢日志以及一些命令的实现. 可能也得之后有时间再刷刷看了.

明确一下目标: 很喜欢C语言, 准备找时间看看 << C 和指针 >>, 然后买本轮子哥一直推的 << C++ Primer 5 >> , 越来越发现底层的世界, 真的是很好玩啊! 特别是, 对于每一块内存, 随心所欲的控制, 这种感觉真的是爽爆了!!!

压缩列表 (ziplist) 是列表键和哈希键的底层实现之一.

  1. 当一个列表键只包含少量列表项, 并且每个列表项要么就是小整数值, 要么就是长度比较短的字符串, 那么 Redis 就会使用压缩列表来做列表键的底层实现.
  2. 当一个哈希键只包含少量键值对, 并且每个键值对的键和值要么就是小整数值, 要么就是长度比较短的字符串, 那么 Redis 就会使用压缩列表来做哈希键的底层实现.

1. 压缩列表的构成

压缩列表是 Redis 为了节约内存而开发的, 由一系列特殊编码的连续内存块组成的顺序型 (sequential) 数据结构.
一个压缩列表可以包含任意多个节点 (entry) , 每个节点可以保存一个字节数组或者一个整数值.

压缩列表的整体布局:

<zlbytes><zltail><zllen><entry><entry><zlend>

zlbytes uint32_t 4 字节 记录整个压缩列表占用的内存字节数: 在对压缩列表进行内存重分配, 或者计算 zlend 的位置时使用.
zltail uint32_t 4 字节 记录压缩列表表尾节点距离压缩列表的起始地址有多少字节: 通过这个偏移量,程序无须遍历整个压缩列表就可以确定表尾节点的地址.
zllen uint16_t 2 字节 记录了压缩列表包含的节点数量: 当这个属性的值小于 UINT16_MAX (65535)时, 这个属性的值就是压缩列表包含节点的数量; 当这个值等于 UINT16_MAX 时, 节点的真实数量需要遍历整个压 缩列表才能计算得出.
entryX 列表节点 不定 压缩列表包含的各个节点,节点的长度由节点保存的内容决定.
zlend uint8_t 1 字节 特殊值 0xFF (十进制 255 ),用于标记压缩列表的末端.

2 压缩列表节点的构成

每个压缩列表节点可以保存一个字节数组或者一个整数值, 其中, 字节数组可以是以下三种长度的其中一种:

  • 长度小于等于 63 (2^{6}-1)字节的字节数组;
  • 长度小于等于 16383 (2^{14}-1) 字节的字节数组;
  • 长度小于等于 4294967295 (2^{32}-1)字节的字节数组;

而整数值则可以是以下六种长度的其中一种:

  • 4 位长,介于 0 至 12 之间的无符号整数;
  • 1 字节长的有符号整数;
  • 3 字节长的有符号整数;
  • int16_t 类型整数;
  • int32_t 类型整数;
  • int64_t 类型整数.

压缩列表节点的构成:
<previous_entry_length><encoding><content>

2.1 previous_entry_length

节点的 previous_entry_length 属性以字节为单位, 记录了压缩列表中前一个节点的长度.

previous_entry_length 属性的长度可以是 1 字节或者 5 字节:

  • 如果前一节点的长度小于 254 字节, 那么 previous_entry_length 属性的长度为 1 字节: 前一节点的长度就保存在这一个字节里面.
  • 如果前一节点的长度大于等于 254 字节, 那么 previous_entry_length 属性的长度为 5 字节: 其中属性的第一字节会被设置为 0xFE (十进制值 254), 而之后的四个字节则用于保存前一节点的长度.

因为节点的 previous_entry_length 属性记录了前一个节点的长度, 所以程序可以通过指针运算, 根据当前节点的起始地址来计算出前一个节点的起始地址.

压缩列表的从表尾向表头遍历操作就是使用这一原理实现的: 只要我们拥有了一个指向某个节点起始地址的指针, 那么通过这个指针以及这个节点的 previous_entry_length 属性, 程序就可以一直向前一个节点回
溯, 最终到达压缩列表的表头节点.

2.2 encoding

节点的 encoding 属性记录了节点的 content 属性所保存数据的类型以及长度:

  • 一字节, 两字节或者五字节长, 值的最高位为 00 , 01 或者 10 的是字节数组编码: 这种编码表示节点的 content 属性保存着字节数组, 数组的长度由编码除去最高两位之后的其他位记录;
  • 一字节长, 值的最高位以 11 开头的是整数编码: 这种编码表示节点的 content 属性保存着整数值, 整数值的类型和长度由编码除去最高两位之后的其他位记录;
编码编码长度content 属性保存的值
00bbbbbb1 字节长度小于等于 63 字节的字节数组.
01bbbbbb xxxxxxxx2 字节长度小于等于 16383 字节的字节数组.
10______ aaaaaaaa bbbbbbbb cccccccc dddddddd5 字节长度小于等于 4294967295 的字节数组.


编码编码长度content 属性保存的值
110000001 字节int16_t 类型的整数.
110100001 字节int32_t 类型的整数.
111000001 字节int64_t 类型的整数.
111100001 字节24 位有符号整数.
111111101 字节8 位有符号整数.
1111xxxx1 字节使用这一编码的节点没有相应的 content 属性, 因为编码本身的 xxxx 四个位已经保存了一个介于 0 和 12 之间的值, 所以它无须 content 属性.

2.3 content

节点的 content 属性负责保存节点的值, 节点值可以是一个字节数组或者整数, 值的类型和长度由节点的 encoding 属性决定.

3. 连锁更新

前面说过, 每个节点的 previous_entry_length 属性都记录了前一个节点的长度:

  • 如果前一节点的长度小于 254 字节, 那么 previous_entry_length 属性需要用 1 字节长的空间来保存这个长度值.
  • 如果前一节点的长度大于等于 254 字节, 那么 previous_entry_length 属性需要用 5 字节长的空间来保存这个长度值.

如果 原有的节点都小于 254 字节, 突然间插入一个大于等于 254 字节, 压缩列表将会发生空间重分配(连锁更新);
删除节点, 也会发生导致连锁更新.

因为连锁更新在最坏情况下需要对压缩列表执行 N 次空间重分配操作, 而每次空间重分配的最坏复杂度为 O(N) , 所以连锁更新的最坏复杂度为 O(N^2).

要注意的是, 尽管连锁更新的复杂度较高, 但它真正造成性能问题的几率是很低的:

  • 首先, 压缩列表里要恰好有多个连续的, 长度介于 250 字节至 253 字节之间的节点, 连锁更新才有可能被引发, 在实际中, 这种情况并不多见;
  • 其次, 即使出现连锁更新, 但只要被更新的节点数量不多, 就不会对性能造成任何影响: 比如说, 对三五个节点进行连锁更新是绝对不会影响性能的;

因为以上原因, ziplistPush 等命令的平均复杂度仅为 O(N) , 在实际中, 我们可以放心地使用这些函数, 而不必担心连锁更新会影响压缩列表的性能.

4. 压缩列表 API

函数 作用 算法复杂度
ziplistNew 创建一个新的压缩列表. O(1)
ziplistPush 创建一个包含给定值的新节点, 并将这个新节点添加到压缩列表的表头或者表尾. 平均 O(N) ,最坏 O(N^2).
ziplistInsert 将包含给定值的新节点插入到给定节点之后. 平均 O(N) ,最坏 O(N^2).
ziplistIndex 返回压缩列表给定索引上的节点. O(N)
ziplistFind 在压缩列表中查找并返回包含了给定值的节点. 因为节点的值可能是一个字节数组, 所以检查节点值和给定值是否相同的复杂度为 O(N) , 而查找整个列表的复杂度则为 O(N^2).
ziplistNext 返回给定节点的下一个节点. O(1)
ziplistPrev 返回给定节点的前一个节点. O(1)
ziplistGet 获取给定节点所保存的值. O(1)
ziplistDelete 从压缩列表中删除给定的节点. 平均 O(N) ,最坏 O(N^2).
ziplistDeleteRange 删除压缩列表在给定索引上的连续多个节点. 平均 O(N) ,最坏 O(N^2).
ziplistBlobLen 返回压缩列表目前占用的内存字节数. O(1)
ziplistLen 返回压缩列表目前包含的节点数量. 节点数量小于 65535 时 O(1) , 大于 65535 时 O(N).

因为 ziplistPush , ziplistInsert , ziplistDelete 和 ziplistDeleteRange 四个函数都有可能会引发连锁更新, 所以它们的最坏复杂度都是 O(N^2).

5. 总结

  • 压缩列表是一种为节约内存而开发的顺序型数据结构.
  • 压缩列表被用作列表键和哈希键的底层实现之一.
  • 压缩列表可以包含多个节点,每个节点可以保存一个字节数组或者整数值.
  • 添加新节点到压缩列表, 或者从压缩列表中删除节点, 可能会引发连锁更新操作, 但这种操作出现的几率并不高.

整数集合(intset)是集合键的底层实现之一: 当一个集合只包含整数值元素, 并且这个集合的元素数量不多时, Redis 就会使用整数集合作为集合键的底层实现.

整数集合 (intset) 是 Redis 用于保存整数值的集合抽象数据结构, 它可以保存类型为 int16_t , int32_t 或者 int64_t 的整数值, 并且保证集合中不会出现重复元素.

1. 整数集合的定义

每个 intset.h/intset 结构表示一个整数集合:

typedef struct intset {
  // 编码方式
  uint32_t encoding;
  // 集合包含的元素数量
  uint32_t length;
  // 保存元素的数组
  int8_t contents[];
} intset;

contents 数组是整数集合的底层实现: 整数集合的每个元素都是 contents 数组的一个数组项 (item) , 各个项在数组中按值的大小从小到大有序地排列, 并且数组中不包含任何重复项.

length 属性记录了整数集合包含的元素数量, 也即是 contents 数组的长度.

虽然 intset 结构将 contents 属性声明为 int8_t 类型的数组, 但实际上 contents 数组并不保存任何 int8_t 类型的值 -- contents 数组的真正类型取决于 encoding 属性的值:

  • 如果 encoding 属性的值为 INTSET_ENC_INT16 , 那么 contents 就是一个 int16_t 类型的数组, 数组里的每个项都是一个 int16_t 类型的整数值 (最小值为 -32,768 , 最大值为 32,767 );
  • 如果 encoding 属性的值为 INTSET_ENC_INT32 , 那么 contents 就是一个 int32_t 类型的数组, 数组里的每个项都是一个 int32_t 类型的整数值 (最小值为 -2,147,483,648 , 最大值为 2,147,483,647 );
  • 如果 encoding 属性的值为 INTSET_ENC_INT64 , 那么 contents 就是一个 int64_t 类型的数组, 数组里的每个项都是一个 int64_t 类型的整数值 (最小值为 -9,223,372,036,854,775,808 , 最大值为 9,223,372,036,854,775,807 ).

2. 升级

每当我们要将一个新元素添加到整数集合里面, 并且新元素的类型比整数集合现有所有元素的类型都要长时, 整数集合需要先进行升级 (upgrade) , 然后才能将新元素添加到整数集合里面.

升级整数集合并添加新元素共分为三步进行:

  1. 根据新元素的类型, 扩展整数集合底层数组的空间大小, 并为新元素分配空间;
  2. 将底层数组现有的所有元素都转换成与新元素相同的类型, 并将类型转换后的元素放置到正确的位上, 而且在放置元素的过程中, 需要继续维持底层数组的有序性质不变;
  3. 将新元素添加到底层数组里面.

因为每次向整数集合添加新元素都可能会引起升级, 而每次升级都需要对底层数组中已有的所有元素进行类型转换, 所以向整数集合添加新元素的时间复杂度为 O(N).

3. 升级之后新元素的摆放位置

因为引发升级的新元素的长度总是比整数集合现有所有元素的长度都大, 所以这个新元素的值要么就大于所有现有元素, 要么就小于所有现有元素:

  1. 在新元素小于所有现有元素的情况下, 新元素会被放置在底层数组的最开头 (索引 0 ) ;
  2. 在新元素大于所有现有元素的情况下, 新元素会被放置在底层数组的最末尾 (索引 length-1 ).

4. 升级的好处

4.1 提升灵活性

因为 C 语言是静态类型语言, 为了避免类型错误, 我们通常不会将两种不同类型的值放在同一个数据结构里面.

比如说, 我们一般只使用 int16_t 类型的数组来保存 int16_t 类型的值, 只使用 int32_t 类型的数组来保存 int32_t 类型的值, 诸如此类.

但是, 因为整数集合可以通过自动升级底层数组来适应新元素, 所以我们可以随意地将 int16_t , int32_t 或者 int64_t 类型的整数添加到集合中, 而不必担心出现类型错误, 这种做法非常灵活.

4.2 节约内存

当然, 要让一个数组可以同时保存 int16_t , int32_t , int64_t 三种类型的值, 最简单的做法就是直接使用 int64_t 类型的数组作为整数集合的底层实现. 不过这样一来, 即使添加到整数集合里面的都是 int16_t 类型或者 int32_t 类型的值, 数组都需要使用 int64_t 类型的空间去保存它们, 从而出现浪费内存的情况.

而整数集合现在的做法既可以让集合能同时保存三种不同类型的值, 又可以确保升级操作只会在有需要的时候进行, 这可以尽量节省内存.

比如说, 如果我们一直只向整数集合添加 int16_t 类型的值, 那么整数集合的底层实现就会一直是 int16_t 类型的数组, 只有在我们要将 int32_t 类型或者 int64_t 类型的值添加到集合时, 程序才会对数组进行升级.

5. 降级

整数集合不支持降级操作, 一旦对数组进行了升级, 编码就会一直保持升级后的状态.

6. 整数集合 API

函数 作用 时间复杂度
intsetNew 创建一个新的整数集合. O(1)
intsetAdd 将给定元素添加到整数集合里面. O(N)
intsetRemove 从整数集合中移除给定元素. O(N)
intsetFind 检查给定值是否存在于集合. 因为底层数组有序,查找可以通过二分查找法来进行, 所以复杂度为 O(log N).
intsetRandom 从整数集合中随机返回一个元素. O(1)
intsetGet 取出底层数组在给定索引上的元素. O(1)
intsetLen 返回整数集合包含的元素个数. O(1)
intsetBlobLen 返回整数集合占用的内存字节数. O(1)

7. 总结

  • 整数集合是集合键的底层实现之一.
  • 整数集合的底层实现为数组, 这个数组以有序, 无重复的方式保存集合元素, 在有需要时, 程序会根据新添加元素的类型, 改变这个数组的类型.
  • 升级操作为整数集合带来了操作上的灵活性, 并且尽可能地节约了内存.
  • 整数集合只支持升级操作, 不支持降级操作.

跳跃表 (skiplist) 是一种有序数据结构, 它通过在每个节点中维持多个指向其他节点的指针, 从而达到快速访问节点的目的.

跳跃表支持平均 O(log N) 最坏 O(N) 复杂度的节点查找, 还可以通过顺序性操作来批量处理节点.

在大部分情况下, 跳跃表的效率可以和平衡树相媲美, 并且因为跳跃表的实现比平衡树要来得更为简单, 所以有不少程序都使用跳跃表来代替平衡树.

Redis 使用跳跃表作为有序集合键的底层实现之一: 如果一个有序集合包含的元素数量比较多, 又或者有序集合中元素的成员 (member) 是比较长的字符串时, Redis 就会使用跳跃表来作为有序集合键的底层实现.

和链表, 字典等数据结构被广泛地应用在 Redis 内部不同, Redis 只在两个地方用到了跳跃表, 一个是实现有序集合键, 另一个是在集群节点中用作内部数据结构, 除此之外, 跳跃表在 Redis 里面没有其他用途.

1. 跳跃表节点

跳跃表节点由 redis.h/zskiplistNode 结构定义:

typedef struct zskiplistNode {
    // 后退指针
    struct zskiplistNode *backward;
    // 分值
    double score;
    // 成员对象
    robj *obj;
    // 层
    struct zskiplistLevel {
        // 前进指针
        struct zskiplistNode *forward;
        // 跨度
        unsigned int span;
    } level[];
} zskiplistNode;

1.1 层

跳跃表节点的 level 数组可以包含多个元素, 每个元素都包含一个指向其他节点的指针, 程序可以通过这些层来加快访问其他节点的速度, 一般来说, 层的数量越多, 访问其他节点的速度就越快.

每次创建一个新跳跃表节点的时候, 程序都根据幂次定律 (power law,越大的数出现的概率越小) 随机生成一个介于 1 和 32 之间的值作为 level 数组的大小, 这个大小就是层的 “高度”.

1.2 前进指针

每个层都有一个指向表尾方向的前进指针 (level[i].forward 属性), 用于从表头向表尾方向访问节点.

1.3 跨度

层的跨度(level[i].span 属性)用于记录两个节点之间的距离:

  1. 两个节点之间的跨度越大, 它们相距得就越远.
  2. 指向 NULL 的所有前进指针的跨度都为 0 , 因为它们没有连向任何节点.

跨度用来计算排位 (rank) : 在查找某个节点的过程中, 将沿途访问过的所有层的跨度累计起来, 得到的结果就是目标节点在跳跃表中的排位.

1.4 后退指针

节点的后退指针 (backward) 用于从表尾向表头方向访问节点, 它每次只能后退至前一个节点.

1.5 分值和成员

节点的分值 (score) 是一个 double 类型的浮点数, 跳跃表中的所有节点都按分值 从小到大 排序.

节点的成员对象 (obj) 是一个指针, 它指向一个 字符串对象, 而字符串对象则保存着一个 SDS 值.

在同一个跳跃表中, 各个节点保存的 成员对象必须是唯一的 , 但是多个节点保存的 分值却可以是相同的 : 分值相同的节点将按照成员对象在字典序中的大小来进行排序, 成员对象较小的节点会排在前面(靠近表头的方向), 而成员对象较大的节点则会排在后面(靠近表尾的方向).

2. 跳跃表

使用一个 zskiplist 结构来持有节点, 可以更方便地访问跳跃表的表头节点和表尾节点, 又或者快速地获取跳跃表节点
的数量 (也即是跳跃表的长度) 等信息.

zskiplist 结构的定义如下 (redis.h/zskiplist):

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

headertail 指针分别指向跳跃表的表头和表尾节点, 程序定位表头节点和表尾节点的复杂度为 O(1) .

length 属性记录节点的数量, 可在 O(1) 复杂度内返回跳跃表的长度.

level 则用于在 O(1) 复杂度内获取跳跃表中层高最大的那个节点的层数量, 注意表头节点的层高并不计算在内.

3. 跳跃表 API

函数 作用 时间复杂度
zslCreate 创建一个新的跳跃表. O(1)
zslFree 释放给定跳跃表,以及表中包含的所有节点. O(N),N 为跳跃表的长度.
zslInsert 将包含给定成员和分值的新节点添加到跳跃表中. 平均 O(log N),最坏 O(N),N 为跳跃表长度.
zslDelete 删除跳跃表中包含给定成员和分值的节点. 平均 O(log N),最坏 O(N),N 为跳跃表长度.
zslGetRank 返回包含给定成员和分值的节点在跳跃表中的排位. 平均 O(log N),最坏 O(N),N 为跳跃表长度.
zslGetElementByRank 返回跳跃表在给定排位上的节点. 平均 O(log N),最坏 O(N),N 为跳跃表长度.
zslIsInRange 给定一个分值范围(range), 比如0 到15 ,20 到28 ,诸如此类, 如果给定的分值范围包含在跳跃表的分值范围之内, 那么返回1 ,否则返回0 . 通过跳跃表的表头节点和表尾节点, 这个检测可以用 O(1) 复杂度完成.
zslFirstInRange 给定一个分值范围, 返回跳跃表中第一个符合这个范围的节点. 平均 O(log N),最坏 O(N).N 为跳跃表长度.
zslLastInRange 给定一个分值范围, 返回跳跃表中最后一个符合这个范围的节点. 平均 O(log N),最坏 O(N).N 为跳跃表长度.
zslDeleteRangeByScore 给定一个分值范围, 删除跳跃表中所有在这个范围之内的节点. O(N),N 为被删除节点数量.
zslDeleteRangeByRank 给定一个排位范围, 删除跳跃表中所有在这个范围之内的节点. O(N),N 为被删除节点数量.

4. 总结

  • 跳跃表是有序集合的底层实现之一, 除此之外它在 Redis 中没有其他应用;
  • Redis 的跳跃表实现由 zskiplist 和 zskiplistNode 两个结构组成, 其中 zskiplist 用于保存跳跃表信息(比如表头节点, 表尾节点, 长度), 而 zskiplistNode 则用于表示跳跃表节点;
  • 每个跳跃表节点的层高都是 1 至 32 之间的随机数;
  • 在同一个跳跃表中, 多个节点可以包含相同的分值, 但每个节点的成员对象必须是唯一的;
  • 跳跃表中的节点按照分值大小进行排序, 当分值相同时, 节点按照成员对象的大小进行排序.

Redis 的数据库使用字典实现, 对数据库的增, 删, 查, 改也是构建在对字典的操作之上的.

字典是哈希键的底层实现之一: 当一个哈希键包含的键值对比较多, 又或者键值对中的元素都是比较长的字符串时, Redis 将会使用字典作为哈希键的底层实现.

1. 哈希表

Redis 的字典使用哈希表作为底层实现, 一个哈希表里面可以有多个哈希表节点, 而每个哈希表节点就保存了字典中的一个键值对.

Redis 字典所使用的哈希表由 dict.h/dictht 结构定义:

typedef struct dictht {
    // 哈希表数组
    dictEntry **table;
    // 哈希表大小
    unsigned long size;
    // 哈希表大小掩码,用于计算索引值
    // 总是等于 size - 1
    unsigned long sizemask;
    // 该哈希表已有节点的数量
    unsigned long used;
} dictht;

table 属性是一个数组, 数组中的每个元素都是一个指向 dict.h/dictEntry 结构的指针, 每个 dictEntry 结构保存着一个键值对.

size 属性记录了哈希表的大小, 也即是 table 数组的大小, 而 used 属性则记录了哈希表目前已有节点(键值对)的数量.

sizemask 属性的值总是等于 size - 1 , 这个属性和哈希值一起决定一个键应该被放到 table 数组的哪个索引上面.

2. 哈希表节点

哈希表节点使用 dictEntry 结构表示, 每个 dictEntry 结构都保存着一个键值对:

typedef struct dictEntry {
    // 键
    void *key;
    // 值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;
    // 指向下个哈希表节点,形成链表
    struct dictEntry *next;
} dictEntry;
  • key 键
  • v 值
  • next 指向下一个哈希表节点指针
  1. 值可以是一个 指针, uint64_t 整数, int64_t 整数;
  2. next 可以将多个哈希值相同的键值对连接在一次, 以此解决键冲突的问题.

3.字典

Redis 中的字典由 dict.h/dict 结构表示:

typedef struct dict {
    // 类型特定函数
    dictType *type;
    // 私有数据
    void *privdata;
    // 哈希表
    dictht ht[2];
    // rehash 索引
    // 当 rehash 不在进行时,值为 -1
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */
} dict;

type 属性和 privdata 属性是针对不同类型的键值对, 为创建多态字典而设置的:

  1. type 属性是一个指向 dictType 结构的指针, 每个 dictType 结构保存了一簇用于操作特定类型键值对的函数, Redis 会为用途不同的字典设置不同的类型特定函数;
  2. privdata 属性则保存了需要传给那些类型特定函数的可选参数.
typedef struct dictType {
    // 计算哈希值的函数
    unsigned int (*hashFunction)(const void *key);
    // 复制键的函数
    void *(*keyDup)(void *privdata, const void *key);
    // 复制值的函数
    void *(*valDup)(void *privdata, const void *obj);
    // 对比键的函数
    int (*keyCompare)(void *privdata, const void *key1, const void *key2);
    // 销毁键的函数
    void (*keyDestructor)(void *privdata, void *key);
    // 销毁值的函数
    void (*valDestructor)(void *privdata, void *obj);
} dictType;

ht 属性是一个包含两个项的数组, 数组中的每个项都是一个 dictht 哈希表, 一般情况下, 字典只使用 ht[0] 哈希表, ht[1] 哈希表只会在对 ht[0] 哈希表进行 rehash 时使用.

除了 ht[1] 之外, 另一个和 rehash 有关的属性就是 rehashidx : 它记录了 rehash 目前的进度, 如果目前没有在进行 rehash, 那么它的值为 -1.

4. 哈希算法

当要将一个新的键值对添加到字典里面时, 程序需要先根据键值对的键计算出哈希值和索引值, 然后再根据索引值, 将包含新键值对的哈希表节点放到哈希表数组的指定索引上
面.

Redis 计算哈希值和索引值的方法如下:

# 使用字典设置的哈希函数,计算键 key 的哈希值
hash = dict->type->hashFunction(key);
# 使用哈希表的 sizemask 属性和哈希值,计算出索引值
# 根据情况不同, ht[x] 可以是 ht[0] 或者 ht[1]
index = hash & dict->ht[x].sizemask;

当字典被用作数据库或哈希键的底层实现时, Redis 使用 MurmurHash2 算法来计算键的哈希值.

MurmurHash 算法目前的最新版本为 MurmurHash3 , 而 Redis 使用的是 MurmurHash2, 关于 MurmurHash 算法的更多信息可以参考该算法的主页: http://code.google.com/p/smhasher/.

该算法已经迁移到 GitHub: https://github.com/aappleby/smhasher


然而, 我在 GitHub 上搜索 Redis 的相关源码, 发现版本不同, 使用的哈希算法也是不相同的:

最新版本的 Redis (5.0已发布), 采用的是 SipHash 哈希算法, 链接:
https://github.com/antirez/redis/blob/unstable/src/dict.c#L84

往回看, 5.0, 4.0 都是 SipHash 哈希算法:

https://github.com/antirez/redis/blob/5.0/src/dict.c#L84

https://github.com/antirez/redis/blob/4.0/src/dict.c#L84

3.2, 3.0, 2.8, 2.6 都是 MurmurHash2 哈希算法:

https://github.com/antirez/redis/blob/3.2/src/dict.c#L92

https://github.com/antirez/redis/blob/3.0/src/dict.c#L92

https://github.com/antirez/redis/blob/2.8/src/dict.c#L92

https://github.com/antirez/redis/blob/2.6/src/dict.c#L98

而更旧的 2.4 2.2, 作者没有说是什么算法, 但是让我回想到 鸟哥 的一篇文章, 讲的是 PHP 的哈希算法, 看样子很像, 估计是 DJBX33A (Daniel J. Bernstein, Times 33 with Addition) 算法.

PHP中的Hash算法

https://github.com/antirez/redis/blob/2.4/src/dict.c#L88

https://github.com/antirez/redis/blob/2.2/src/dict.c#L88

关于哈希算法的, 还找到了两篇文章:

漫谈非加密哈希算法
我为什么要使用哈希


5. 解决键冲突

当有两个或以上数量的键被分配到了哈希表数组的同一个索引上面时, 我们称这些键发生了冲突(collision).

Redis 的哈希表使用链地址法(separate chaining)来解决键冲突: 每个哈希表节点都有一个 next 指针, 多个哈希表节点可以用 next 指针构成一个单向链表, 被分配到同一个索引上的多个节点可以用这个单向链表连接起来, 这就解决了键冲突的问题.

因为 dictEntry 节点组成的链表没有指向链表表尾的指针, 为了速度考虑, 程序总是将新节点添加到链表的表头位置, 排在已有节点前面, 操作的复杂度为 O(1).

6. rehash

当哈希表保存的键值对数量太多或者太少时, 程序需要对哈希表的大小进行相应的扩展或者收缩.

扩展和收缩哈希表的工作可以通过执行 rehash (重新散列) 操作来完成, Redis 对字典的哈希表执行 rehash 的步骤如下:

  1. 为字典的 ht[1] 哈希表分配空间, 这个哈希表的空间大小取决于要执行的操作, 以及 ht[0] 当前包含的键值对数量 (也即是 ht[0].used 属性的值):

    • 如果执行的是扩展操作, 那么 ht[1] 的大小为第一个大于等于 ht[0].used * 2 的 2^n (2 的 n 次方幂);
    • 如果执行的是收缩操作, 那么 ht[1] 的大小为第一个大于等于 ht[0].used 的 2^n .
  2. 将保存在 ht[0] 中的所有键值对 rehash 到 ht[1] 上面: rehash 指的是重新计算键的哈希值和索引值, 然后将键值对放置到 ht[1] 哈希表的指定位置上.
  3. 当 ht[0] 包含的所有键值对都迁移到了 ht[1] 之后 (ht[0] 变为空表), 释放 ht[0] , 将 ht[1] 设置为 ht[0] , 并在 ht[1] 新创建一个空白哈希表, 为下一次 rehash 做准备.

7. 哈希表的扩展与收缩

当以下条件中的任意一个被满足时, 程序会自动开始对哈希表执行扩展操作:

  1. 服务器目前没有在执行 BGSAVE 命令或者 BGREWRITEAOF 命令, 并且哈希表的负载因子大于等于 1;
  2. 服务器目前正在执行 BGSAVE 命令或者 BGREWRITEAOF 命令, 并且哈希表的负载因子大于等于 5. (感觉书错了, 应该是 0.5 ...)

其中哈希表的负载因子可以通过公式计算得出:

# 负载因子 = 哈希表已保存节点数量 / 哈希表大小
load_factor = ht[0].used / ht[0].size

根据 BGSAVE 命令或 BGREWRITEAOF 命令是否正在执行, 服务器执行扩展操作所需的负载因子并不相同, 这是因为在执行 BGSAVE 命令或 BGREWRITEAOF 命令的过程中, Redis 需要创建当前服务器进程的子进程, 而大多数操作系统都采用写时复制 (copy-on-write) 技术来优化子进程的使用效率, 所以在子进程存在期间, 服务器会提高执行扩展操作所需的负载
因子, 从而尽可能地避免在子进程存在期间进行哈希表扩展操作, 这可以避免不必要的内存写入操作, 最大限度地节约内存.

另一方面, 当哈希表的负载因子小于 0.1 时, 程序自动开始对哈希表执行收缩操作.

8. 渐进式 rehash

为避免 rehash 对服务器性能造成影响, 服务器不是一次性将 ht[0] 里面的所有键值对全部 rehash 到 ht[1] , 而是分多次, 渐进式地将 ht[0] 里面的键值对慢慢地 rehash 到 ht[1].

以下是哈希表渐进式 rehash 的详细步骤:

  1. 为 ht[1] 分配空间, 让字典同时持有 ht[0] 和 ht[1] 两个哈希表;
  2. 在字典中维持一个索引计数器变量 rehashidx , 并将它的值设置为 0 , 表示 rehash 工作正式开始;
  3. 在 rehash 进行期间, 每次对字典执行添加, 删除, 查找或者更新操作时, 程序除了执行指定的操作以外, 还会顺带将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1] , 当 rehash 工作完成之后, 程序将 rehashidx 属性的值增 1;
  4. 随着字典操作的不断执行, 最终在某个时间点上, ht[0] 的所有键值对都会被 rehash 至 ht[1] , 这时程序将 rehashidx 属性的值设为 -1 , 表示 rehash 操作已完成.

渐进式 rehash 的好处在于它采取分而治之的方式, 将 rehash 键值对所需的计算工作均滩到对字典的每个添加, 删除, 查找和更新操作上, 从而避免了集中式 rehash 而带来的庞大计算量.

9. 字典 API

函数 作用 时间复杂度
dictCreate 创建一个新的字典. O(1)
dictAdd 将给定的键值对添加到字典里面. O(1)
dictReplace 将给定的键值对添加到字典里面, 如果键已经存在于字典,那么用新值取代原有的值. O(1)
dictFetchValue 返回给定键的值. O(1)
dictGetRandomKey 从字典中随机返回一个键值对. O(1)
dictDelete 从字典中删除给定键所对应的键值对. O(1)
dictRelease 释放给定字典,以及字典中包含的所有键值对. O(N),N为字典包含的键值对数量.

10. 总结

  • 字典被广泛用于实现 Redis 的各种功能, 其中包括数据库和哈希键;
  • Redis 中的字典使用哈希表作为底层实现, 每个字典带有两个哈希表, 一个用于平时使用, 另一个仅在进行 rehash 时使用.
    当字典被用作数据库的底层实现, 或者哈希键的底层实现时, Redis 使用 MurmurHash2 算法来计算键的哈希值;
  • 哈希表使用链地址法来解决键冲突, 被分配到同一个索引上的多个键值对会连接成一个单向链表;
  • 在对哈希表进行扩展或者收缩操作时, 程序需要将现有哈希表包含的所有键值对 rehash 到新哈希表里面, 并且这个 rehash 过程并不是一次性地完成的, 而是渐进式地完成的.