Redis哈希表源码深度解析，技术大牛力荐，助你掌握底层数据结构

2025年3月15日，Redis实验室发布了关于内存数据结构优化的一篇新博客，提到了渐进式哈希在超大规模数据集下的新应用思路。同年1月，有核心开发者在技术论坛讨论中再次强调了理解字典结构对性能调优的关键性。

哈希表是Redis的万能钥匙

你可能知道Redis很快，但它的快离不开精巧的设计。哈希表在Redis里就像一把万能钥匙，不只是用来存字符串对应关系，它其实是整个Redis内部最核心的底层结构之一。几乎所有的主要数据类型，比如我们常用的哈希键（Hash）、集合（Set），甚至整个Redis的数据库，都是用哈希表或者它的变体来实现的。想象一下，你存一个用户对象，里面有名字、年龄、城市，Redis内部可能就是用一个哈希表来存这些字段和值。所以，把这个结构搞明白，就等于掀开了Redis高性能的秘密盖子。

字典里藏着的两张表与渐进式搬家

Redis的哈希表源码里，最关键的一个结构叫“字典”。它里面其实藏着两张哈希表，通常只用一张。那为什么要有两张呢？这就为了在需要扩容或者缩容的时候，能平滑地“搬家”。这个过程叫“渐进式重哈希”。它不是一次性把成千上万的数据从旧表搬到新表，那样会卡住Redis。而是每次有用户来读写数据时，顺手搬那么一两个键值对过去，同时还在两张表里查找。这样，搬家过程虽然慢点，但服务一直可用，用户几乎感觉不到。这个过程就像你一边住着老房子，一边慢慢把家具搬到新家，两边的门都开着，生活不受影响。在深入这些底层细节时，手边有一个好用的开发工具箱会方便很多。

冲突了怎么办？链表来帮忙

再好的哈希函数，也可能把不同的钥匙算到同一个柜子编号里，这就是“哈希冲突”。Redis处理冲突的办法很经典，叫“链地址法”。简单说，就是如果同一个位置要放多个键值对，那就用一根链表把它们串起来，挂在这个位置下面。查找的时候，先找到位置，再顺着链表一个个对比钥匙。为了效率，当链表太长时，Redis会把它转换成一棵叫“跳跃表”的小树，这样查找更快。源码里这些判断和转换的逻辑，体现了设计者对于速度和内存的精细平衡。

从源码视角看调优启示

看源码不是为了炫技，而是为了真正用好。理解了Redis哈希表的这些门道，你就能明白一些最佳实践背后的原因。比如，为什么我们建议哈希键里的字段不要太多，最好别超过几千个？因为如果字段太多，在扩容或者查找长链表时，性能可能会有波动。又比如，为什么有时候删除大量数据后，内存占用似乎没减少？这可能是因为触发了缩容条件，但Redis为了谨慎起见，缩容没有扩容那么积极。知道了这些，你在设计数据和监控系统时，心里就更有谱了，能提前规避一些潜在的性能坑。

本文内容参考了Redis 7.2.x版本源码（主要是dict.c, dict.h文件），并结合了《Redis设计与实现》一书中的相关解读，以及Redis官方文档关于数据类型的说明。