Redis2.2.2源码学习——dict中的hashtable扩容和rehash

Redis2.2.2

dict是Redis的hash数据结构，所有类型的元素都可以依据key值计算hashkey，然后将元素插入到dict的某个hash链上（采用拉链法解决hash冲突）。其中，dict的中的hashtable(dictht)的扩容是dict很重要的部分。Redis的“管家”函数serverCron会依据一定的算法（dict中的used与size的比值）判定是否开始进行hashtable的扩容。dict中的ht[1]是作为扩容的临时数据，扩容之后，hashtalbe的长度将变长，那么hashtalbe的masksize与原来的makssize就不同了，那么计算出的hashkey也将不同。所以就需要Rehash对ht[0]中的元素重新计算hashkey。

在Rehash阶段，首先将原来的ht[0]中的元素重新rehash到ht[1]中，故而要耗费大量的力气从新计算原来的ht[0]表中元素的在ht[1]表总的hashkey，并将元素转移到ht[1]的表中。由于这样Rehash会耗费大量的系统资源，如果一次性完成一个dict的Rehash工作，那么将会对系统中的其他任务造成延迟？ 作者的处理方式是：同样在serverCron中调用rehash相关函数，1ms的时间限定内，调用rehash()函数，每次仅处理少量的转移任务(100个元素)。这样有点类似于操作系统的时间片轮转的调度算法。

下图是Dict相关数据结构（引用： Redis源码剖析(经典版).docx ）

代码分析如下：

*/int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData)/*记录sever调用serverCron的总次数*对于需要协调的不同的任务，可以依据loops%n的方式设置不同的频率*/int loops = server.cronloops 。。。/* We don't want to resize the hash tables while a bacground saving     * is in progress: the saving child is created using fork() that is     * implemented with a copy-on-write semantic in most modern systems, so     * if we resize the HT while there is the saving child at work actually     * a lot of memory movements in the parent will cause a lot of pages     * copied. 后台没有对数据进行操作的程序...*/    if (server.bgsavechildpid == -1 && server.bgrewritechildpid == -1) {/*loops % 10 : serverCron没循环10次，进行一次tryResizeHashTables检查*/        if (!(loops % 10)) tryResizeHashTables();//下面的for是tryResizeHashTables源码>for (j = 0; j < server.dbnum; j++) {//htNeedsResize：检查used*100/size < REDIS_HT_MINFILL(设定的阈值)if (htNeedsResize(server.db[j].dict)) dictResize(server.db[j].dict);//见下文分析 扩容Resizeif (htNeedsResize(server.db[j].expires))dictResize(server.db[j].expires);>}        if (server.activerehashing) incrementallyRehash();//见下文分析 Rehash    }------------------------扩容Resize------------------------------------------/* Resize the table to the minimal size that contains all the elements, * but with the invariant of a USER/BUCKETS ratio near to <= 1 */int dictResize(dict *d){    int minimal;    if (!dict_can_resize || dictIsRehashing(d)/*rehashidx ?= -1*/) return DICT_ERR;    minimal = d->ht[0].used;    if (minimal < DICT_HT_INITIAL_SIZE)        minimal = DICT_HT_INITIAL_SIZE;//minimal = Max(d->ht[0].used,DICT_HT_INITIAL_SIZE)//原来的容量为size，现要扩充到used或DICT_HT_INITIAL_SIZE    return dictExpand(d, minimal);}/* Expand or create the hashtable */int dictExpand(dict *d, unsigned long size){    dictht n; /* the new hashtable *///将size扩展到2^n : while(1) { if (i >= size) return i; i *= 2; }    unsigned long realsize = _dictNextPower(size);    /* the size is invalid if it is smaller than the number of     * elements already inside the hashtable */    if (dictIsRehashing(d) || d->ht[0].used > size)        return DICT_ERR;    /* Allocate the new hashtable and initialize all pointers to NULL */    n.size = realsize;    n.sizemask = realsize-1;    n.table = zcalloc(realsize*sizeof(dictEntry*));    n.used = 0;    /* 如果是在dict的第一次申请空间？那么就直接将n赋给d->ht[0]，而且不需要rehash */    if (d->ht[0].table == NULL) {        d->ht[0] = n;        return DICT_OK;    }    /* Prepare a second hash table for incremental rehashing */    d->ht[1] = n;    d->rehashidx = 0;// rehashidx! = -1; 表示d进入了rehash阶段    return DICT_OK;}-------------------------Rehash-----------------------------------------/*记得前文：serverCron作为一个定时器事件的处理函数，定时的时间为1ms在serverCron会调用incrementallyRehash()函数去不断的完成rehash任务。这里说“不断的"的意思是，rehash的任务不是一次性的函数调用完成的，可能需要serverCron调用多次incrementallyRehash()来完成。下文就是incrementallyRehash()函数和子函数的额调用关系，incrementallyRehash()的执行限时为1ms，在这时间内，dictRehash()会以一定量任务(100)为单元进行d->ht的转移。*/incrementallyRehash(void)遍历server.db[],对db中的dict进行rehash，每个dict的限定时间为1msdictRehashMilliseconds(server.db[j].dict,1)while(dictRehash的执行时间<1ms)dictRehash(d,100)//详见下文源码将dict->ht[1]取出100个元素(dictEntry) Rehash到dict->ht[0]/* Performs N steps of incremental rehashing. Returns 1 if there are still * keys to move from the old to the new hash table, otherwise 0 is returned. * Note that a rehashing step consists in moving a bucket (that may have more * thank one key as we use chaining) from the old to the new hash table. *//*将依次将d->ht[1].table[]中的元素搬到d->ht[0].table[]，修改相关的used。d->rehashidx：记录着当前的hashtable中搬了那一条链表的索引下标d->ht[0].table[d->rehashidx] => d->ht[0].table[d->rehashidx]完成一个dict的Rehash后，重置d->rehashidx = -1 */int dictRehash(dict *d, int n) {    if (!dictIsRehashing(d)) return 0;    while(n--) {        dictEntry *de, *nextde;        /* Check if we already rehashed the whole table... *///d->ht[0].used == 0 : 说明d->ht[0] 已经全部搬到 d->ht[1]        if (d->ht[0].used == 0) {            zfree(d->ht[0].table);            d->ht[0] = d->ht[1];            _dictReset(&d->ht[1]);            d->rehashidx = -1;//该dict的Rehash结束 设置为 -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;}