redis_字典_哈希hash

字典、哈希表基本数据结构

redis字典使用哈希表作为底层实现，基本结构就是数组+散列

typedef struct dictht {
    // 哈希表数组
    dictEntry **table;
    // 哈希表数组的大小
    unsigned long size;
    // 掩码，用于计算新加入的元素的index（sizemask值等于size-1）
    unsigned ling sizemask;
    // 哈希表中已有节点的数量
    unsigned long used;
} dictht;

其中，哈希表数组中的每一个节点，与1.8之前的jdk中map很相似，也是链表结构

typedef struct dictEntry {
    // 键
    void *key
    // 值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;
    // 指向下个哈希表节点，形成链表
    struct dictEntry *next;
} dictEntry;

最终的redis字典内部，由2个哈希表构成。平时只使用其中的一个，当需要扩展或收缩哈希表时，启用第二个，后续详细介绍

redis字典结构如下：

typedef struct dict {
    dictType *type
    void *privdata;
    // 哈希表（实际存储数据），平时使用ht[0]，当需要扩展或收缩哈希表时，将ht[0]的数据rehash到ht[1]，然后释放ht[0]，将ht[1]设置为ht[0]，并在ht[1]新建一个空白哈希表，done
    dictht ht[2];
    // 是否正在执行rehash的标识，不在进行时为-1
    int trehashidx;
} dictEntry;

下面介绍一些hash操作常遇到的问题：index选择、index冲突、rehash触发条件、rehash流程

index选择

index选择和jdk类似

• 首先计算出哈希值 hash = dict -> type -> hashFunction(key);
• 再位运算 index = hash & dict -> ht[0].sizemask;
  • 注意，这要求ht[0]的大小为2的n次幂，方便hash值被按位与到哈希表的大小里

index冲突

采用链地址方法，冲突的节点被添加在冲突链的头部。不会变成树，就是链

rehash触发条件

哈希表的扩展、收缩会触发rehash，这里和jdk不类似了

扩展条件（满足任意一个即可）：

• 负载因子（已保存节点数量ht[0].used / 哈希表大小ht[0].size） >=1、且服务器目前没有在执行 BGSAVE 或 BGREWRITEAOF
• 负载因子 >=5、且服务器目前在执行 BGSAVE 或 BGREWRITEAOF

收缩条件：

• 负载因子 < 0.1

rehash流程

在rehash发生之前，数据都保存在两个哈希表中的第一个ht[0]中，从这里开始rehash流程：

1. 为ht[1]分配空间。
   • 如果是扩展，则ht[1]大小为大于等于ht[0].used * 2 的第一个2的n次幂。比如ht[0]大小为16，used为17，则扩展后大小为64
   • 如果是收缩，则ht[1]大小为大于等于ht[0].used 的第一个2的n次幂。比如ht[0]大小为128，used为10，则收缩后大小为16
2. 将ht[0]的所有键值对rehash到ht[1]，即重新计算哈希、重新计算索引、重新处理冲突
3. 释放ht[0]
4. 将ht[1]设置为ht[0]，并在ht[1]创建一个新的空白哈希表

渐进式rehash：

当键值对很多时，一次性rehash从ht[0]到ht[1]耗时耗资源很大，redis会分多次完成ht[0]到ht[1]

• 渐进式rehash时，新增操作直接保存到ht[1]，其他入删除、更新、查找等都会先操作ht[0]再操作ht[1]

这里性能影响、如何分批还不是很清楚