来源:寒食君
作者:寒食君i
那个深夜,我登上了公司的服务器,在Redis 命令行里敲入 keys*
后,线上开始报警,服务瞬间被卡死,我只能举起双手,焦急地等待几千万key被慢慢扫描,束手无策万念俱灰的时候,我收到了leader的短信:你明天不用来上班了。
虽然上面是我的臆想,事实上很多公司的运维也会禁用这些命令,来防止开发出错。但我在群里依然看到有同学在问“为什么Redis不能用 keys
?我觉得挺好的呀”时,为了不让上面的情况发生,我决定写下这篇文章。
如何才能优雅地遍历Redis?作为一种可以称为数据库的组件,这是多么理所因当的要求。终于,Redis在2.8.0版本新增了众望所归的 scan
操作,从此再也不用担心敲入了keys*, 然后等着定时炸弹的引爆。
学会使用 scan
并不困难,那么问题又来了,它是如何遍历的?当遍历过程中加入了新的key,当遍历过程中发生了扩容,Redis是如何解决的?抱着深入学习的态度,以及为了能够将来在面试官面前谈笑风生,让我们一起来借此探索Redis的设计原理。
开门见山,首先让我们来总结一下 scan
的优缺点。
优点:
缺点:
所以scan是一个能够满足需求,但也不是完美无瑕的命令。
下面来介绍一下原理,scan到底是如何实现的?scan,hscan等命令主要都是借用了通用的scan操作函数:scanGenericCommand 。
scanGenericCommand 函数分为4步:
当迭代一个哈希表时,存在三种情况:
在这三种情况之下,sacn是如何实现的?
首先需要知道的前提是:Redis中进行rehash扩容时会存在两个哈希表,ht[0]与ht[1],rehash是渐进式的,即不会一次性完成。新的键值对会存放到ht[1]中并且会逐步将ht[0]的数据转移到ht[1].全部rehash完毕后,ht[1]赋值给ht[0]然后清空ht[1].
这个过程比较简单,一般来说只需要最简单粗暴的顺序迭代就可以了,这种情况下没什么好说的。
但是字典的大小是能够进行自动扩容的,我们不得不考虑以下两个问题:
第一,假如字典扩容了,变成2倍的长度,这种情况下,能够保证一定能遍历所有最初的key,但是却会出现大量重复。举个例子:
比如当前的key数组大小是4,后来变为8了。假如从下表0,1,2,3顺序扫描时,如果数组已经发生扩容,那么前面的0,1,2,3slot里面的数据会发生一部分迁移到对应的4,5,6,7slot里面去,当扫描到4,5,6,7的slot时,无疑会出现值重复的情况。
需要知道的是,Redis按如下方法计算一个当前key扩容后的slot:hash(key)&(size-1)
如图,当从字典大小从4扩容到8时,原先在0 slot的数据会分散到0(000)与4(100)两个slot,对应关系表如下:
第二, 如果字典缩小了,比如从16缩小到8, 原先scan已经遍历了0,1,2,3 ,如果数组已经缩小。这样后来迭代停止在7号slot,但是8,9,10,11这几个slot的数据会分别合并到0,1,2,3里面去,从而scan就没有扫描出这部分元素出来,无法保证可用性。
上面考虑的情况是,在迭代过程的间隙中,rehash已经完成。那么会不会出现迭代进行中,切换游标时,rehash也正在进行?当然可能会发生。
如果返回游标1时正在进行rehash,那么ht[0](扩容之前的表)中的slot1中的部分数据可能已经rehash到 ht[1](扩容之后的表)中的slot1或者slot4,此时必须将ht[0]和ht[1]中的相应slot全部遍历,否则可能会有遗漏数据,但是这么做好像也非常麻烦。
为了解决以上两个问题,Redis使用了一种称为:reverse binary iteration的算法。源码如下:
unsignedlong dictScan(dict *d, unsignedlong v, dictScanFunction *fn, void*privdata){
if(!dictIsRehashing(d)) {
t0 = (d->ht[0]);
m0 = t0->sizemask;
/* Emit entries at cursor */
while(de) {
fn(privdata, de);
de = de->next;
}
} else{
m0 = t0->sizemask;
m1 = t1->sizemask;
de = t0->table[v & m0];
while(de) {
fn(privdata, de);
de = de->next;
}
do{
de = t1->table[v & m1];
while(de) {
fn(privdata, de);
de = de->next;
}
v = (((v | m0) + 1) & ~m0) | (v & m0);
} while(v & (m0 ^ m1));
}
v |= ~m0;
v = rev(v);
v++;
v = rev(v);
return v;
}
一起来理解下核心源码,第一个if,else主要通过dictIsRehashing这个函数来判断是否正在rehash;sizemask指的是字典空间长度,假如长度为16,那么sizemask的二进制为00001111。m0 代表当前字典的长度,v代表游标所在的索引值。接下来关注这个片段:
v |= ~m0;
v = rev(v);
v++;
v = rev(v);
这段代码初看好像有点摸不着头脑,怎么多次在多次rev?我们来看下在字典长度从4 rehash到8时,scan是如何迭代的。
当字典长度为4时,m0等于4,二进制表示为00000011,那么~m0为11111100,v初始值为0,那么 v |= ~m0为11111100。接下来看图:
可以看到,第一次dictScan后,游标从0变成了2,四次遍历分别为 0 -> 2 -> 1 -> 3,四个值都遍历到了。
在字典长度为8时,遍历情况如下:
遍历顺序为:0 -> 4 -> 2 -> 6 -> 1 -> 5 -> 3 -> 7
是不是察觉了什么?遍历顺序是不是顺序是一致的?如果还没发现,不妨再来看看字典长度为16时的遍历情况,以及三次顺序的对比:
让我们设想这么一个情况,字典的大小本身为4,开始迭代,当游标刚迭代完slot0时,返回的下一个游标时slot2,此时发现字典的大小已经从4rehash到8,那么不妨继续从size为8的hashtable中slot2处继续迭代。有人会说,不是把slot4遗漏掉了吗?
注意之前所说的扩容方式:hash(key)&(size-1),slot0和slot4的内容是相同的,巧妙地避开了重复,当然,更不会遗漏。
如果你看到这里,你可能会发出和我一样的感慨:我X,这算法太牛X了。没错,上面的算法是由Pieter Noordhuis设计实现的,Redis之父Salvatore Sanfilippo对该算法的评价是”Hard to explain but awesome。“
字典扩大的情况没问题,那么缩小的情况呢?可以仿照着自己思考一下具体步骤。答案是可能会出现重复迭代,但是不会出现遗漏,也能够保证可用性。
迭代过程中,进行过rehash这种情况下的迭代已经比较完美地解决了,那么迭代过程中,正在进行rehash的情况是如何解决的呢?
我们继续看源码,之前提到过dictIsRehashing这个函数用来判断是否正在进行rehash,那么主要就是关注这段源码:
m0 = t0->sizemask;
m1 = t1->sizemask;
de = t0->table[v & m0];
while(de) {
fn(privdata, de);
de = de->next;
}
do{
de = t1->table[v & m1];
while(de) {
fn(privdata, de);
de = de->next;
}
v = (((v | m0) + 1) & ~m0) | (v & m0);
} while(v & (m0 ^ m1));
m0代表rehash前的字典长度,假设为4,即00000011,m1代表rehash后的字典长度,假设为8,即00000111。
首先当前游标 &
m0可以得到较小字典中需要迭代的slot的索引,然后开始循环迭代。
然后开始较大字典的迭代,首先我们关注一下循环条件:
v & (m0 ^ m1)
m0,m1二者经过异或操作后的值为00000100,可以看到只留下了最高位的值。游标v与之做 &
操作,将其作为判断条件,即判断游标v在最高位是否还有值。当高位为0时,说明较大字典已经迭代完毕。(因为较大字典的大小是较小字典的两倍,较大字典大小的最高位一定是1)
到此为止,我们已经将scan的核心源码通读一遍了,相信很多其间的迷惑也随之解开。不仅在写代码的时候更自信了,假如日后被面试官问起相关问题,那绝对可以趁机表现一番,想想还有点小激动。
参考:https://segmentfault.com/a/1190000018218584