Redis 的基础数据结构（一） 可变字符串、链表、字典

这篇文章关于 Redis 的基础数据。阅读这篇文章你能够了解：

• 动态字符串（SDS）
• 链表
• 字典

三个数据结构 Redis 是怎么实现的。

SDS

SDS (Simple Dynamic String) 是 Redis 最基础的数据结构。直译过来就是"简单的动态字符串"。Redis实现了一个动态字符串，而不是直接使用了C语言中的字符串。

sds数据结构：

struct sdshdr {
    
    // buf 中已占用空间的长度
    int len;

    // buf 中剩余可用空间的长度
    int free;

    // 数据空间
    char buf[];
};

因此一个 SDS 的就以下图：

因此咱们看到，sds 包含3个参数。buf 的剩余长度，buf 的长度 len，以及buf。

为何这么设计呢？

• 能够直接获取字符串长度。
  C 语言中，获取字符串的长度须要用指针遍历字符串，时间复杂度为 O(n)，而 SDS 的长度，直接从len 获取复杂度为 O(1)。

• 杜绝缓冲区溢出。
  因为C 语言不记录字符串长度，若是增长一个字符传的长度，若是没有注意就可能溢出，覆盖了紧挨着这个字符的数据。对于SDS 而言增长字符串长度须要验证 free的长度，若是free 不够就会扩容整个 buf，防止溢出。

• 减小修改字符串长度时形成的内存再次分配。
  redis 做为高性能的内存数据库，须要较高的相应速度。字符串也很大几率的频繁修改。 SDS 经过未使用空间这个参数，将字符串的长度和底层buf的长度之间的额关系解除了。buf的长度也不是字符串的长度。基于这个分设计 SDS 实现了空间的预分配和惰性释放。

  1. 预分配
     若是对 SDS 修改后，若是 len 小于 1MB 那 len = 2 * len + 1byte。 这个 1 是用于保存空字节。
     若是 SDS 修改后 len 大于 1MB 那么 len = 1MB + len + 1byte。
  2. 惰性释放
     若是缩短 SDS 的字符串长度，redis并非立刻减小 SDS 所占内存。只是增长 free 的长度。同时向外提供 API 。真正须要释放的时候，才去从新缩小 SDS 所占的内存

• 二进制安全。
  C 语言中的字符串是以 ”\0“ 做为字符串的结束标记。而 SDS 是使用 len 的长度来标记字符串的结束。因此SDS 能够存储字符串以外的任意二进制流。由于有可能有的二进制流在流中就包含了”\0“形成字符串提早结束。也就是说 SDS 不依赖 “\0” 做为结束的依据。

• 兼容C语言
  SDS 按照惯例使用 ”\0“ 做为结尾的管理。部分普通C 语言的字符串 API 也可使用。

链表

C语言中并无链表这个数据结构因此 Redis 本身实现了一个。Redis 中的链表是：

typedef struct listNode {

    // 前置节点
    struct listNode *prev;

    // 后置节点
    struct listNode *next;

    // 节点的值
    void *value;

} listNode;

很是典型的双向链表的数据结构。

同时为双向链表提供了以下操做的函数：

/*
 * 双端链表迭代器
 */
typedef struct listIter {

    // 当前迭代到的节点
    listNode *next;

    // 迭代的方向
    int direction;

} listIter;

/*
 * 双端链表结构
 */
typedef struct list {

    // 表头节点
    listNode *head;

    // 表尾节点
    listNode *tail;

    // 节点值复制函数
    void *(*dup)(void *ptr);

    // 节点值释放函数
    void (*free)(void *ptr);

    // 节点值对比函数
    int (*match)(void *ptr, void *key);

    // 链表所包含的节点数量
    unsigned long len;

} list;

链表的结构比较简单，数据结构以下：

总结一下性质：

• 双向链表，某个节点寻找上一个或者下一个节点时间复杂度 O(1)。
• list 记录了 head 和 tail，寻找 head 和 tail 的时间复杂度为 O(1)。
• 获取链表的长度 len 时间复杂度 O(1)。

字典

字典数据结构极其相似 java 中的 Hashmap。

Redis的字典由三个基础的数据结构组成。最底层的单位是哈希表节点。结构以下：

typedef struct dictEntry {
    
    // 键
    void *key;

    // 值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;

    // 指向下个哈希表节点，造成链表
    struct dictEntry *next;

} dictEntry;

实际上哈希表节点就是一个单项列表的节点。保存了一下下一个节点的指针。 key 就是节点的键，v是这个节点的值。这个 v 既能够是一个指针，也能够是一个 uint64_t或者 int64_t 整数。*next 指向下一个节点。

经过一个哈希表的数组把各个节点连接起来：

typedef struct dictht {
    
    // 哈希表数组
    dictEntry **table;

    // 哈希表大小
    unsigned long size;
    
    // 哈希表大小掩码，用于计算索引值
    // 老是等于 size - 1
    unsigned long sizemask;

    // 该哈希表已有节点的数量
    unsigned long used;

} dictht;

dictht

经过图示咱们观察：

实际上，若是对java 的基本数据结构了解的同窗就会发现，这个数据结构和 java 中的 HashMap 是很相似的，就是数组加链表的结构。

字典的数据结构：

typedef struct dict {

    // 类型特定函数
    dictType *type;

    // 私有数据
    void *privdata;

    // 哈希表
    dictht ht[2];

    // rehash 索引
    // 当 rehash 不在进行时，值为 -1
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */

    // 目前正在运行的安全迭代器的数量
    int iterators; /* number of iterators currently running */

} dict;

其中的dictType 是一组方法，代码以下：

/*
 * 字典类型特定函数
 */
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;

字典的数据结构以下图：

这里咱们能够看到一个dict 拥有两个 dictht。通常来讲只使用 ht[0],当扩容的时候发生了rehash的时候，ht[1]才会被使用。

当咱们观察或者研究一个hash结构的时候偶咱们首先要考虑的这个 dict 如何插入一个数据？

咱们梳理一下插入数据的逻辑。

• 计算Key 的 hash 值。找到 hash 映射到 table 数组的位置。

• 若是数据已经有一个 key 存在了。那就意味着发生了 hash 碰撞。新加入的节点，就会做为链表的一个节点接到以前节点的 next 指针上。

• 若是 key 发生了屡次碰撞，形成链表的长度愈来愈长。会使得字典的查询速度降低。为了维持正常的负载。Redis 会对 字典进行 rehash 操做。来增长 table 数组的长度。因此咱们要着重了解一下 Redis 的 rehash。步骤以下：

  1. 根据ht[0] 的数据和操做的类型（扩大或缩小），分配 ht[1] 的大小。
  2. 将 ht[0] 的数据 rehash 到 ht[1] 上。
  3. rehash 完成之后，将ht[1] 设置为 ht[0]，生成一个新的ht[1]备用。

• 渐进式的 rehash 。
  其实若是字典的 key 数量很大，达到千万级以上，rehash 就会是一个相对较长的时间。因此为了字典可以在 rehash 的时候可以继续提供服务。Redis 提供了一个渐进式的 rehash 实现，rehash的步骤以下：

  1. 分配 ht[1] 的空间，让字典同时持有 ht[1] 和 ht[0]。
  2. 在字典中维护一个 rehashidx，设置为 0 ，表示字典正在 rehash。
  3. 在rehash期间，每次对字典的操做除了进行指定的操做之外，都会根据 ht[0] 在 rehashidx 上对应的键值对 rehash 到 ht[1]上。
  4. 随着操做进行， ht[0] 的数据就会所有 rehash 到 ht[1] 。设置ht[0] 的 rehashidx 为 -1，渐进的 rehash 结束。

这样保证数据可以平滑的进行 rehash。防止 rehash 时间太久阻塞线程。

• 在进行 rehash 的过程当中，若是进行了 delete 和 update 等操做，会在两个哈希表上进行。若是是 find 的话优先在ht[0] 上进行，若是没有找到，再去 ht[1] 中查找。若是是 insert 的话那就只会在 ht[1]中插入数据。这样就会保证了 ht[1] 的数据只增不减，ht[0]的数据只减不增。