Redis哈希结构内存模型剖析

概述

在前文《Redis字符串范例内部编码分解》之中已经分解过 Redis最根基的 String范例的内部是怎么编码和存储的，本文再来叙述 Redis中行使 最为频仍的数据范例：哈希（或称散列），在Redis内部是怎么存的。

• 尝试源码情形：Redis 4.0.10

注： 本文首发于 My Personal Blog，接待降临 小站

本文内容脑图如下：

哈希范例内部编码详情

对付 Redis的常用 5 种数据范例（String、Hash、List、Set、sorted set），每种数据范例都提供了 起码两种 内部的编码名目，并且每个数据范例内部编码方法的选择 对用户是完全透明的，Redis会按照数据量自顺应地选择较优化的内部编码名目。

假如想查察某个键的内部编码名目，可以行使 OBJECT ENCODING keyname 指令来举办，好比：

127.0.0.1:6379>   
127.0.0.1:6379> set foo bar  
OK  
127.0.0.1:6379>   
127.0.0.1:6379> object encoding foo  // 查察某个Redis键值的编码  
"embstr"  
127.0.0.1:6379>   
127.0.0.1:6379>  

对付行使最为频仍的 Hash范例，其内部编码方法也许有两种：

•  OBJ_ENCODING_ZIPLIST（压缩列表）
•  OBJ_ENCODING_HT（哈希表）

Redis 会按照数据量的环境来自顺应地选择这两种编码方法中 较优 的一种，而这统统对用户完全透明。

在 数据条目较少，数据值较小 的时辰 Redis会回收 压缩列表（OBJ_ENCODING_ZIPLIST）编码方法举办存储。这里成员"较少"，成员值"较小"的尺度可以通过如下设置项举办设置：

hash-max-ziplist-entries 512  
hash-max-ziplist-value 64 

Redis 默认给出了默认值，虽然用户可按照现实环境自行设置。

当 Hash范例键的字段个数 < hash-max-ziplist-entries 而且 每个字段名和字段值的长度 < hash-max-ziplist-value 时，Redis 会行使 OBJ_ENCODING_ZIPLIST来存储该键，反之则会转换为 OBJ_ENCODING_HT的编码方法。

口说无凭，我们不妨先来做个尝试感觉一下吧：

很明明该尝试验证了当 字段值长度大于64时，编码名目会由 ZIPLIST方法切换为 Hashtable方法。

源码之前，了无奥秘，我们再来看一下Redis关于这部门切换的源码实现，那就领略得越发清晰了：

下面详解 OBJ_ENCODING_ZIPLIST 和 OBJ_ENCODING_HT 这两种编码名目标内部存储模子，知道了其各自特点和优弱点，天然也就大白了Redis内部行使它们的意图。

OBJ_ENCODING_ZIPLIST 编码

Ziplist 压缩列表是一种紧凑编码名目，总体头脑是时刻换空间，即以部门读写机能为价钱，来调换极高的内存空间操作率，因此只会用于 字段个数少，且字段值也较小 的场景。

压缩列表内存操作率极高的缘故起因与其持续内存的特征是分不开的，其典范的内存布局可以用下图形象地展示出来：

以是假如用 Ziplist来存储 Redis的散列范例的话，元素的分列方法就酿成了如下图所示的形象表示图：即key和value都是逻辑持续内存：

OBJ_ENCODING_HT 编码

OBJ_ENCODING_HT 这种编码方法内部才是真正的哈希表布局，或称为字典布局，其可以实现O(1)伟大度的读写操纵，因此服从很高。

在 Redis内部，从 OBJ_ENCODING_HT范例到底层真正的散列表数据布局是一层层嵌套下去的，相关如下：

这一相关我们可以从 Redis哈希表界说部门的源码来看出：

下面来详解一下各个部门：

•  关于哈希节点（dictEntry）

•  关于哈希表（dictht）和字典（dict）

•  关于dictType

•  Redis怎样计较Hash值

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!