Redis 源码分析(二) 一个 rehash 也不阻塞的哈希表

Redis 的架构设计挺巧妙的,舍弃了主流的多线程架构,别出心裁的使用单线程架构,说实话,作为一个 kv,我一开始认为多线程并行的访问应该是一个默认选项,但是 Redis 的高效,用事实证明,这显然不是。这个单线程的事件系统另开一坑再聊吧,今天主要是看一下这个有趣的哈希表。

typedef struct dict {
    dictType *type;
    void *privdata;
    dictht ht[2];
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */
    int iterators; /* number of iterators currently running */
} dict;

这就是 Redis 里面存哈希表的数据结构,真正的哈希表是哪个 dictht,dictht[0] 是一个哈希表,dictht[1] 是另一个哈希表。这里两个哈希表的设计主要是为了完成一个操作—— rehash,并且是不阻塞的 rehash。
哈希表中最耗时的操作就是 rehash 了,作为一个单线程生物,Redis 不会另外开一个线程去搞这个事情,增删改查还有 rehash 都在一个线程里跑,那么如何能让 rehash 的过程不影响其他的操作呢?
我们来随便找一个哈希表的操作函数,就拿哈希表的查找函数来讲吧

dictEntry *dictFind(dict *d, const void *key)
{
    dictEntry *he;
    unsigned int h, idx, table;

    if (d->ht[0].size == 0) return NULL; /* We don't have a table at all */
    if (dictIsRehashing(d)) _dictRehashStep(d);// 注意
    h = dictHashKey(d, key);
    for (table = 0; table <= 1; table++) {
        idx = h & d->ht[table].sizemask;
        he = d->ht[table].table[idx];
        while(he) {
            if (dictCompareHashKeys(d, key, he->key))
                return he;
            he = he->next;
        }
        if (!dictIsRehashing(d)) return NULL;
    }
    return NULL;
}

如果你看了我上一篇文章的话,这个函数应该已经见过了,同样不需要看整个函数,只需要看我标注的地方就好了,就一行,意思呢,很明白,这个哈希表是不是在 rehash 呀?如果是的话执行 _dictRehashStep 这个函数(开头加了个 _ 这个符号,假装私有函数。。)这个函数是什么意思呢?

static void _dictRehashStep(dict *d) {
    if (d->iterators == 0) dictRehash(d,1);
}

里面那个 dictRehash 是执行 rehash 的地方,直接进来

int dictRehash(dict *d, int n) {
    if (!dictIsRehashing(d)) return 0;

    while(n--) {
        dictEntry *de, *nextde;

        /* Check if we already rehashed the whole table... */
        if (d->ht[0].used == 0) {
            _dictFree(d->ht[0].table);
            d->ht[0] = d->ht[1];
            _dictReset(&d->ht[1]);
            d->rehashidx = -1;
            return 0;
        }

        /* Note that rehashidx can't overflow as we are sure there are more
         * elements because ht[0].used != 0 */
        while(d->ht[0].table[d->rehashidx] == NULL) d->rehashidx++;
        de = d->ht[0].table[d->rehashidx];
        /* Move all the keys in this bucket from the old to the new hash HT 简单说就是找到我们该搬的桶,搬空它,然后结束战斗,就只搬一个桶*/
        while(de) {
            unsigned int h;

            nextde = de->next;
            /* Get the index in the new hash table */
            h = dictHashKey(d, de->key) & d->ht[1].sizemask;
            de->next = d->ht[1].table[h];
            d->ht[1].table[h] = de;
            d->ht[0].used--;
            d->ht[1].used++;
            de = nextde;
        }
        d->ht[0].table[d->rehashidx] = NULL;
        d->rehashidx++;
    }
    return 1;
}

上文代码中的中文应该很引人注目(因为代码还是不如人话好懂啊~),这里这个函数就是找到这个哈希表中需要被搬运的第一个桶,然后把这个桶里面的所有项一个个重新哈希一下,搬到第二个哈希表中,就是从 dictht 中的 ht[0] 搬运到 ht[1],然后结束之后,指针交换一下就可以了呀。
既然了解了这个搬运工函数的作用,我们来看一下哪些部分调用了这个函数呢?
dictAdd
dictFind
dictGenericDelete
增删改查(改是先删再add)里面都用到了呀,也就是在线上不停的增删改查中不知不觉就 rehash 完了,一个 O(n) 的操作就这样变成了均摊 O(1) 的,当然不会阻塞啦。
Redis 是一个在线服务,其数据结构也是根据这个特性来设计的,把一个大的操作均摊到每个细小的操作中来降低算法复杂度,这种思想并不罕见,比如带懒惰标记的线段树,伸展树,STL 中的 vector 也是均摊的来算复杂度,这种方法虽然有点耍赖皮,但是相当实用啊。
下一讲来讲 Redis 的事件系统吧,这个系统一方面使得 Redis 效率极高,另一方面也降低了很多的编码复杂度,也是一个精妙的设计。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值