download：SpringBoot+Vue3 项目实战，打造企业级在线办公系统
Redis哈希表使用链地址方法解决键冲突！# # #重新散列的步骤
1).为字典的ht[1]哈希表分配空间。这个哈希表的大小取决于要执行的操作和ht[0]中当前包含的键值对的数量(即ht[0]的值)。已用属性)
如果是扩展操作，那么ht[1]的大小是大于等于ht[0].used2的第一个数，是2的n次方，例如ht[0]。用过的=10，那么102 = 20；只需找出2的n次方中刚好大于或等于20的数。2的4次方是16 ^ 2，2的5次方是32，所以这个数是32。如果是收缩运算，那么ht[1]的大小就是大于等于ht[0]的第一个数。使用并且是2的n次方，例如ht[0]。已用=10。只需找出2的n次方中刚好大于或等于10的数字。
2)将存储在ht[0]中的所有键值对重新散列到ht[1]中。3)当ht[0]包含的所有键值对都迁移到ht[1]时(迁移是指从ht[0]迁移到ht[1])。此时，ht[0]已经是一个空表。释放ht[0]，然后将ht[1]设置为ht[0]并在ht[1]中创建新的
哈希表什么时候会自动扩展？
目前服务器没有执行BGSAVE命令或BGREWRITEAOF命令，哈希表的加载因子大于等于1。服务器正在执行BGSAVE命令或BGREWRITEAOF命令，哈希表的加载因子大于或等于5。其中，哈希表的加载因子为load _ factor = ht [0]。已用/ht [0]大小。Redis在执行BGSAVE或BGREWRITEAOF命令的过程中，需要创建一个当前服务器进程的子进程，大多数操作系统都采用写时复制技术来优化子进程的使用效率。因此，提供了复杂度因子，以尽可能避免子进程存在时的哈希表扩展操作。
当哈希表的加载因子小于0.1时，会自动开始收缩哈希表# # #渐进式重散列。
为了避免重散列对服务器性能的影响，服务器不会一次重散列ht[0]到ht[1]中的所有键值对，而是将ht[0]到ht[1]中的键值对逐渐重散列几次。渐进式再散列步骤:
为ht[1]分配空间，让字典同时保存ht[0]和ht[1]两个哈希表，并自动维护一个索引计数器变量rehashidx，并将其值设为0，表示重新哈希工作正式开始。在重散列过程中，每次添加、删除和检查字典时，除了这些操作之外，程序还会顺便将ht[0]散列表的rehashidx索引上的所有键-值对重散列到ht[1]。重散列完成后，程序将添加、删除和检查一次rehashidx属性，然后从具有重散列索引的数组中迁移。相当于把重散列所需的计算工作分摊到词典的每一次增删改上，避免了集中重散列带来的巨大计算量。
# #渐进式重新哈希执行期间的哈希表操作
在重散列过程中，字典会同时使用两个哈希表ht[0]和ht[1]，所以在重散列过程中，字典会被删除并在两个哈希表上进行检查；但是，这种添加只会在ht[1]中进行；###redis字典如何重散列？数据量这么大如何保证重散列不会影响性能？redis采用渐进式重散列法，平均分担重散列过程，每一次增删查都是一次重散列；