IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签:dict

共 3 篇相关文章

IT 累计浏览 1,934

深入剖析 redis 数据结构 dict

这篇深度技术文章从源码层面拆解了 Redis 的核心数据结构——字典(dict)。作者首先指明,Redis 的每个数据库(db)本质上由两个哈希表(dictht)构成,真正存储键值对的是这两个表。文章重点剖析了 Redis 哈希表设计最精妙的部分:为何需要两个哈希表,以及如何利用它们实现 **渐进式 rehash(重哈希)**,从而在服务不中断的前提下完成表的扩容。 具体实现上,当触发扩展时,Redis 会为第二个哈希表分配新空间,并在后续的每次增删改查操作中,分批次地将数据从旧表迁移至新表。文章结合源码(`dictRehash` 函数)展示了这一“逐步搬家”的过程,并点明了其背后的设计考量:在服务器空闲时,定时任务会推进 rehash;在高负载时,操作本身的开销也会承担部分 rehash 工作,以此平衡性能。 此外,文章还分析了这种设计带来的“副作用”:由于查找操作需同时兼顾两个表,加上写操作本身包含多次查找,导致 Redis 在执行 SET 等写命令时效率并不高,这也从底层解释了其“重读轻写”的特性。最后,文章简要介绍了在涉及持久化(如 RDB/AOF)遍历哈希表时,也需要正确处理这两个表的过渡状态。全文逻辑清晰,从结构定义到核心算法,再到其对上层行为的影响,层层递进,非常适合想深入理解 Redis 高性能背后实现细节的开发者。

IT 累计浏览 1,621

深入剖析 redis 数据结构 intset

这篇讲的是 Redis 中整数集合 intset 的底层实现细节。当 set 中所有元素都是整数时,Redis 会优先使用 intset 这种紧凑的数据结构,只有遇到非整数时才升级为更通用的 dict。作者深入源码,拆解了 intset 如何做到高效存储与操作。 intset 本质是一个有序、不重复的整型数组。它的精巧之处在于通过 `encoding` 字段动态记录当前数组中整数的位宽(16、32或64位),从而在保证功能的前提下极致节省内存。查找操作直接利用数组的有序特性,采用经典的二分查找算法,效率很高。 文章的重点和亮点在于对插入过程的剖析。当插入的新整数超出了当前编码范围(例如向一个全是 16 位整数的集合插入一个 32 位整数),intset 不会简单拒绝,而是会触发一次“编码升级”(`intsetUpgradeAndAdd`)。升级过程非常巧妙:它会重新分配内存,将现有所有元素转换为新编码,并逆序移动元素以避免数据覆盖。由于新整数必然是最大或最小值,最终将其放置在数组头部或尾部即可。这种按需升级的设计,平衡了内存效率与灵活性。 整体来看,intset 是一个为特定场景高度优化的微型数据结构。它通过有序数组+二分查找+动态编码升级,为 Redis 提供了一个内存极其友好且高效的整数集合实现,是理解 Redis 空间优化哲学的一个绝佳范例。

IT 累计浏览 4,569

redis源代码分析 - hash table

这篇深入剖析了Redis核心数据结构之一——哈希表(dict)的实现。作者从`dict.c`源码出发,揭示了Redis如何用一个结构同时管理两张哈希表(`ht[0]`和`ht[1]`),并在`rehash`过程中巧妙地通过“渐进式迁移”来避免阻塞。 文章的关键在于讲清楚了“渐进式rehash”的运作机制:当需要扩容或收缩时,Redis并不会一次性完成迁移,而是将rehash过程分散到后续的每一次增删改查操作中,每次只迁移一小部分。同时,它详细说明了触发rehash的负载因子阈值,以及在rehash期间如何通过一个标志位确保操作的正确性。 这种设计使得即使在处理百万级键值的大型哈希表时,Redis也能保持极低的延迟。文章将这个精巧的工程实现拆解得清晰易懂,展现了Redis为追求高性能而做出的底层权衡与智慧。