redis-dict中

dict

  今天是哈希表的中篇,花了很大的篇幅来描述哈希表,足以证明这个结构的重要性了。redis就是基于哈希的一个设计,而且如今的分布式都和哈希有着密切的关系。redis的数据结构部分结束后,计划增加哈希表的应用,布隆过滤器和一致性哈希,这两个是哈希结构比较典型的两个场景,一个是关于大数据的,一个关于分布式的。当然也会有其它数据结构的实战操作,比如链表,链表和哈希表的结合等等。下面进入正题,今天会涉及以下部分:

  • 解决哈希碰撞
  • rehash
  • 源码

解决哈希冲突

  什么是哈希碰撞?让我们回顾一下哈希函数的第三个特征,不同的输入可能对应相同的输出,即哈希碰撞。

为什么出现哈希碰撞

  学习一个东西必须从问题出发,那么究竟是什么原因呢?同学们肯定还记得哈希函数的第一个特征-输入域是无穷大的,输出域是有限的。函数是一种映射,而且很容易看出是多对一的映射关系,这种映射必然会导致哈希碰撞。

解决方法

  • 拉链法
  • 开放定址法
  • 再哈希法
  • 公共溢出区法

  出了问题能怎么办,just do it.如果通过哈希函数计算的值映射到数组后,数组索引处已经有元素了,那么把每个数组元素的类型定义成链表或者是节点类型就好了。
  或许会有疑惑,到底使用链表还是节点类型?使用头插法还是尾插法呢?首先第一个问题redis采用了节点类型,因为不需要辅助变量去获得链表的长度信息,首元节点和尾节点,这些对于哈希表是没什么价值的。其次第二个问题redis使用了头插法,头插法的优势很明显,直接插入就可以,而尾插法需要遍历一下单链表。
  说实话,三儿基本上只用过拉链法,简单易懂好实现。之前看golang的map的实现时。好像是结合了拉链法和公共溢出区两种方法,emmmm,毕竟当时没有把整个过程浏览一遍,只是大概的看了下map底层的数据结构,不看就没有发言权。所以就不猜测了,如果同学们对别的方法感兴趣可以找一本数据结构的书。

rehash

  如果哈希表不断的添加而没有rehash的过程那么就太扯了。所谓的rehash就是随着不断的添加,我们需要给数组扩容,然后将原来所有的节点重新通过hash函数映射到新的数组上。

为什么要rehash

  链表的长度不能无限的增长,如果链表长度太长,那么查找效率就会大大降低。

什么时候需要rehash

  是否需要进行rehash是通过负载因子(节点个数/数组容量)决定的,java中的默认为0.75,java采用0.75是根据数学统计的,这时可以保证基本每条链表的长度都小于8,拨云见日,其实负载因子就是在控制链表长度,使得链表不要太长,以保证搜索的效率。
  redis是直接计算每条链的平均长度的,当长度超过预定的阈值后,就要进行一次rehash。redis的阈值设置的是5。
  多说一句,在经典的哈希表结构中,如果有一条链的长度超过阈值,那么就会rehash,这是因为哈希函数的第四条特征,既然碰撞是等概率的,那么如果一条链长度达到了阈值,那么可以认为所有链的长度都达到了阈值。下面的代码if语句的最后一个判断条件就是我们上述描述的redis rehash的条件。

static int _dictExpandIfNeeded(dict *d)
{
    ...
    //dict_force_resize_ratio == 5
    if (d->ht[0].used >= d->ht[0].size &&
        (dict_can_resize ||
         d->ht[0].used/d->ht[0].size > dict_force_resize_ratio))  //
    {
        return dictExpand(d, d->ht[0].used*2);
    }
    return DICT_OK;
}

  如果对于redis的哈希结构,一条链的长度可能为阈值*数组容量,但是经典哈希不会。但是对于经典哈希也有弊端,如果恰巧添加的所有键值对哈希都映射到同一个位置上,那么可能会不停的扩容。不过这都是非常极端的情况。所以没有什么好坏,只有根据场景的取舍。哈希表这个结构中设计到了非常多的数学知识,比如经典哈希的数组长度都要求质数,而且阈值设定的是7,都是一些概率问题,对于三儿这个数学渣渣,只能安慰自己数学验证过就是这么做,按照步骤来就行。

redis的rehash

  • 渐进rehash
  • 使用两个哈希表
  • 定时rehash
渐进rehash

  虽然控制平均的链长为5,但是如果数组的容量很大,有数百万,数亿的键值对,一次性rehash可能会卡顿一段时间吧,这肯定是不行的啊。所以redis采用了渐进式,每次搬移一条链。当需要rehash时,搬移一条链,接下来的rehash操作会在接下来的任何关于这个字典的增删改查中进行,至于怎么判断是否在rehash的过程中,是通过rehashidx的值,-1代表不需要rehash。

#define dictIsRehashing(d) ((d)->rehashidx != -1)
使用两个哈希表

  既然是渐进rehash,所以就涉及两个哈希表,这就是为什么redis的dict中使用的是一个哈希表数组。这个数组的作用正是为rehash服务的。在进行rehash过程前,只用0号哈希表,一旦需要rehash,那么所有的操作会首先在1号哈希表中进行,如果没有完成的话,再对0号哈希表进行同样的操作。比如增加键值对会直接插入1号哈希表,再比如查询键值对,现在1号中查找,找到即返回结果,否则去0号哈希表中查找,返回最终查找结果。如果0号中已经没有节点了,那么此时交换0号和1号哈希表,并且更新rehashidx。下面的代码中的if语句块描述了这个过程。

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

    /* More to rehash... */
    return 1;
}
定时rehash

  如果在rehash后很久没有对这个字典操作,那么就不进行rehash了吗,redis怎么可能这么草率,redis会有定时任务去解决这个问题。

优化

  拉链法中的单链表可以使用红黑树,这样相对于链表可以减少rehash的次数。既然减少了rehash次数,那么树中的节点必然要比链表的多,所以为了查找效率使用了红黑树。三儿当时为了自己实现一个哈希表,去学习了红黑树,看完了添加的情况就看不下去了,如果同学们有兴趣拿下红黑树,推荐算法的橙皮书,先看2-3树,2-3树的实现就是红黑树,原理很简单,实现难到爆炸。

函数

  进入源码分析部分,任何一个数据结构的算法都是增删改查,不过我们今天只介绍创建函数。

创建

  创建函数基本上就是分配空间,初始化为零值或者需要的值。这并没有什么好学习的,但是dict的创建函数有一些学习的点。那就是尽量每个函数都只做一件事,这件事要尽可能的小。这样就会有较好的复用性,下面的创建函数就复用了一部分重置的函数。虽然这个点非常小,但是作为励志成为优秀的程序猿怎么可以忍受复制粘贴,我们要尽可能的代码复用。有兴趣的可以看一下代码整洁之道或者代码大全,三儿目前对怎么写一份好的代码还基本上没有学习多少。如果理解和同学们有不同之处,可以在三儿的qq群和大家一起讨论。(521625004,欢迎加入)

dict *dictCreate(dictType *type,
        void *privDataPtr)
{
    dict *d = zmalloc(sizeof(*d));

    _dictInit(d,type,privDataPtr);
    return d;
}

int _dictInit(dict *d, dictType *type,
        void *privDataPtr)
{
    _dictReset(&d->ht[0]);
    _dictReset(&d->ht[1]);
    d->type = type;
    d->privdata = privDataPtr;
    d->rehashidx = -1;
    d->iterators = 0;
    return DICT_OK;
}

static void _dictReset(dictht *ht)
{
    ht->table = NULL;
    ht->size = 0;
    ht->sizemask = 0;
    ht->used = 0;
}

  上面需要解释的一点是type和privdata成员的作用,它们是为了处理不同类型的键值对。type用来选择特点类型的一组处理键值对的函数,而privdata是这些键值对处理函数的参数。下面的宏体现了type的多态作用,而privdata可以根据while中的函数指针的调用所在处看到是作为数据使用的。

#define dictHashKey(d, key) (d)->type->hashFunction(key)

unsigned long dictScan(dict *d,
                       unsigned long v,
                       dictScanFunction *fn,
                       dictScanBucketFunction* bucketfn,
                       void *privdata)
{
    //...
    if (!dictIsRehashing(d)) {
    
        //...
        while (de) {
            next = de->next;
            fn(privdata, de);
            de = next;
        }

        //...
    } else {
        //...
    }

    return v;
}

总结

  上篇重点讲了哈希函数,今天重点部分在哈希碰撞和rehash,这就把所有关于哈希表的原理都讲解到了,三儿也提到了哈希表中很多东西都是根据数学特性来的,所以我们不必纠结某些过程,比如我们不需要研究哈希函数怎么设计,为什么java的负载因子是0.75,为什么redis定义的阈值为5等等。我们只需要从宏观的方面上把握哈希表的各个知识点,比如说映射的过程,rehash的过程。今天源码部分的讲解只开了个头,因为剩下的操作都是基于查找的,所以把接下来的增删改查放在下一篇中,并不是三儿偷懒哦。

关于作者

大四学生一枚,分析数据结构,面试题,golang,C语言等知识。QQ交流群:521625004。微信公众号:后台技术栈。
image

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值