51人参与 • 2026-08-31 • Redis
dictht 是 “dictionary hash table” 的缩写,它代表一个最基础的哈希表结构。
它的定义如下(源码在 src/dict.h):
typedef struct dictht {
dictentry **table; // 指向一个 bucket 数组(指针的指针)
unsigned long size; // 哈希表的大小(bucket 数组的长度)
unsigned long sizemask; // 用于计算索引值的掩码,总是等于 size-1
unsigned long used; // 哈希表中已有节点的数量
} dictht;
对每个字段的解释:
一个 dictht 的结构示意图:
dictht +------------------+ | table |-----> [dictentry*] -> [dictentry] -> [dictentry] -> null (index 0) | | [dictentry*] -> null (index 1) | size: 4 | [dictentry*] -> [dictentry] -> null (index 2) | sizemask: 3 | [dictentry*] -> [dictentry] -> [dictentry] -> null (index 3) | used: 8 | +------------------+
(上图展示了一个大小为 4 的哈希表,存储了 8 个元素,说明发生了哈希冲突,并用链表法解决)
dict 是 redis 字典的主结构体,它封装了两个 dictht 和一些管理功能,使得哈希表能够平滑地扩容和缩容(rehashing)。
它的定义如下:
typedef struct dict {
dicttype *type; // 类型特定函数,为实现多态而存在
void *privdata; // 私有数据,传递给类型特定函数的可选参数
dictht ht[2]; // 两个哈希表,为什么是两个?请看下面的解释
long rehashidx; // rehashing 的进度,如果不是 -1 则表示正在进行 rehash
int16_t pauserehash; // rehashing 暂停标志,>0 时表示 rehash 被暂停
} dict;
对每个字段的详细解释:
dictht 是静态的存储单元,而 dict 是动态的管理器。它们最精妙的协作体现在 rehashing(重新散列) 过程中。
随着操作不断执行,哈希表的负载因子 used/size 会变得过大(冲突增多,效率下降)或过小(浪费内存)。为了维持高效性能,需要在适当的时候对哈希表进行扩容或缩容。
在 rehashing 期间如何查找?
查找一个键时,会同时查找 ht[0] 和 ht[1] 两个表,先查 ht[0],如果没找到再查 ht[1]。
| 特性 | dictht (字典哈希表) | dict (字典) |
|---|---|---|
| 角色 | 数据存储单元,一个静态的哈希表数组 | 字典管理器,一个动态的、封装好的字典对象 |
| 核心功能 | 存储键值对数据,处理哈希冲突(链表法) | 管理两个 dictht,实现类型多态,控制 rehashing 流程 |
| 包含关系 | 被 dict 所包含 | 包含两个 dictht (ht[0] 和 ht[1]) |
| rehashing | 是 rehashing 操作的对象 | 是 rehashing 过程的控制器(通过 rehashidx) |
| 类比 | 像是房子的毛坯房(只有房间结构) | 像是房子的业主+装修队(负责管理、维护、扩建房子) |
简单来说:
这种“一个管理器 + 两个存储单元”的设计是 redis 字典实现高效、稳定且能够渐进式扩容的关键。
渐进式rehash(防止主进程被长时间阻塞)

到此这篇关于redis中dictht和dict的实现的文章就介绍到这了,更多相关redis dictht和dict内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
您想发表意见!!点此发布评论
版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。
发表评论