本文主要是介绍【Redis】深入理解 Redis 常用数据类型源码及底层实现(4.详解Hash数据结构)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Hash数据结构
看过前面的介绍，大家应该知道 Redis 的 Hash 结构的底层实现在 6 和 7 是不同的，Redis 6 是 ziplist 和 hashtable，Redis 7 是 listpack 和 hashtable。
我们先使用config get hash*看下 Redis 6 和 Redis 7 的 Hash 结构配置情况（在Redis客户端的命令行界面中使用INFO server可以查看包括版本号等各个信息）
通过Docker拉取一个Redis7的镜像，同样的命令查看相关信息
可以看到Redis7多了hash-max-listpack-entries和hash-max-listpack-value两项，我们先介绍下这四个参数的含义：
- hash-max-ziplist-entries：使用压缩列表保存数据时，哈希集合中最大的元素个数
- hash-max-ziplist-value：使用压缩列表保存数据时，哈希集合中单个元素的最大长度
-
- 单位byte：一个英文字母一个byte
- hash-max-listpack-entries：使用紧凑列表保存数据时，哈希集合中最大的元素个数
- hash-max-listpack-value：使用紧凑列表保存数据时，哈希集合中单个元素的最大长度
上面两张图中的参数都是默认情况，为了方便测试效果我们把这两个值都改小些（如下图）
依次存储不同长度的值，并查看编码方式
有上面两张图可以看到，当同时满足字段个数小于hash-max-ziplist-entries并且字段值都小于hash-max-ziplist-value时，才会使用OBJ_ENCODING_ZIPLIST的编码方式进行存储，二者不满足任意一个就会转换为OBJ_ENCODING_HT的编码方式进行存储，并且不可逆（OBJ_ENCODING_ZIPLIST变成OBJ_ENCODING_HT可以，但是即便存储的数据又满足了上面提到的两个要求，OBJ_ENCODING_HT也不会再变回OBJ_ENCODING_ZIPLIST（反反复复浪费性能），相比较OBJ_ENCODING_HT，OBJ_ENCODING_ZIPLIST会更节省内存空间）。
源码分析
t_hash.c
hashtable在Redis中被称为“字典”，他是一个数组+链表的结构
OBJ_ENCODING_HT这种编码方式内部才是真正的哈希表结构，或称为字典结构，有一个dictEntry，详见下图源代码：
OBJ_ENCODING_HT这种编码方式内部才是真正的哈希结构（或称为字典结构），其可以实现O(1)的时间复杂度的读写操作，因此效率很高，在Redis内部，从OBJ_ENCODING_HT类型到底层真正的散列表数据结构是一层一层嵌套起来的，组织关系如
这篇关于【Redis】深入理解 Redis 常用数据类型源码及底层实现(4.详解Hash数据结构)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
