今天我们来学习下Redis中的字典。在此之前，我们已经分享了非常非常多的关于Redis的知识，可以说，Redis里面有非常多的优秀架构设计，可以讲好几本天。
字典，相信大家已经都不陌生，在之前我们介绍Redis基础资料结构的时候，已经介绍了Redis的字典。Redis的字典，类似于Java中的HashMap，采用的是开杂凑的实现方式。什么是开杂凑呢？首先我们是对key进行杂凑，如果杂凑的值相同的话，我们就使用连结串列进行表示。（所以，我们使用JAVA语言的时候，如果Key是一个类，要实现Hash与Equeals方法）
如果杂凑函式没有设计好，那么可能会有很多个Key的杂凑值相同，我们称之为杂凑碰撞，如果被黑客发现，可能会被设计出一堆Key相同的值拖慢系统效率，我们称之为杂凑攻击。
随着key数量的增多，同一个键值上面的元素会越来越多，由于在同一个键值上面是通过连结串列储存，所以开杂凑的效能会越来越低，这个时候，需要扩容，我们称之为REHASH，一般会是原来杂凑表的两倍。
上图中，原本为1的键值上面有3个元素，经过Rehash后，最多只有2个元素。
Redis的字典有两个开杂凑，正常情况下，只有一个生效。但在进行Rehash的时候，两个开杂凑都会同时生效。为什么会同时生效呢？这正是Redis的精髓设计，渐进式Rehash。因为在Rehash过程中，所有的key都要进行迁移，所以需要占用大量的系统资源，Redis服务又是单执行绪的，在3，5个key的时候Rehash还没有多大的开销，如果是几十万几百万个key呢？步子迈大了，就容易扯淡了。
什么是渐进式Rehash呢？顾名思义，即使慢慢地进行重新杂凑操作，在旧的杂凑表上，会维护一个下标index表示前index个键值已经被迁移到新的杂凑表里面，每次字典进行增删改查操作时，如果判断字典正在进行重新杂凑的动作，就会把index座标上面的迁移到新的杂凑表里面，然后把index增加1，最后才进行具体的命令执行。
那么执行一个index下标需要花多少时间呢？在杂凑表中，理想情况下时一个杂凑对应一个键值，所以理论上每次只需要迁移一个元素即可。
在迁移过程中，查询操作都会优先在新表进行查询，如果查询不到再去旧表进行查询。每次插入资料的时候，也是优先插入新表。就这样，如果有1024个键值，那么在1024次操作后，字典就会迁移到大小为2048的新表，同时新表覆盖旧表，等待下一次重新杂凑。当然你可能会问，如果期间只操作了200次呢？Redis是有维护定时任务，即便客户端不再访问这个杂凑表，也会定时完成重新杂凑。
Redis的这种渐进式的设计，是我们架构中常用的一种设计。特别是在多使用者，高并发的场景下，我们不可能一瞬间完成各种状态的更新，可以借鉴Redis的设计思路，逐步覆盖，最终保证最后状态的成功！好了，有关Redis字典我们就介绍到这里。欢迎大家关注我，近期还准备了一些AI相关的知识，整理后会和大家继续分享。大家的支援是我继续唠嗑的动力。同名公众号（沙茶敏碎碎念）
（此处已新增圈子卡片，请到今日头条客户端检视）
