数据结构

Redis 的 hash 对象采用了两种方式来实现，前面分析过连续内存和非连续内存的优缺点，这里 hash 列表也折中了两种情况。

两种存储结构（代码位置 src/t_hash.c）:

ziplist 编码：

ziplist 编码的哈希对象使用压缩列表作为底层实现，每当有新的键值对要加入到哈希对象时，程序会先将保存了键的压缩列表节点推入压缩列表表尾，然后在将保存了值的压缩列表表尾，因此：

1、保存了同一个键值对的两个节点总是紧挨在一起，保存键的节点在前面，保存值的节点在后面。

2、先添加到哈希对象的键值对会被放在压缩列表的表头方向，而后添加到哈希对象中的键值对会被放在压缩列表的表尾方向。

举个例子：

127.0.0.1:6379> hset profile name "Tom"
(integer) 1
127.0.0.1:6379> hset profile age 25
(integer) 1
127.0.0.1:6379> hset profile career "Programmer"
(integer) 1
127.0.0.1:6379> object encoding profile
"ziplist"
复制代码

数据结构如下：

压缩列表底层实现（profile key 结构）：

hashtable 编码：

编码转换：

同时满足一下两个条件的时候选择 ziplist 编码：

• 哈希对象保存的所有键值对的键和值的字符串长度都小于64 字节；
• 哈希对象保存的简直对数量小于 512 个；不满足这两个条件的哈希对象需要使用 hashtable 编码（可以通过 hash-max-ziplist 和 hash-maxziplist-value 修改）。

举个例子（profile key 结构）：：

127.0.0.1:6379> hset profile desc "Programmer 11111112121v121kl lldklakdkalgam fsfdslkgkskgsklgklsklgklsklgsdkgkskgdsklmvm,,vm,vm,,maafaklglkaklsfakslkf"
(integer) 1
127.0.0.1:6379> object encoding profile
"hashtable"

注意点

• 由 ziplist 转换为 dict 的操作是不可逆的
• 尽可能的使用 ziplist 来作为 hash 底层实现。长度尽可能控制在 1000 以内，否则由于存取操作复杂度 O(n) ， 长列表会导致 CPU 消耗亚种，对象也不要太大
• 两个参数 hash-max-ziplist 和 hash-maxziplist-value 可在配置文件中修改
• ziplist 底层存储对象时， 查找时间负载度为 O(n)

使用场景

• 存储对象（定长或者不定长字符串）
• set user:1:name Mack set user:1:age 23 set user:1:city shanghai 复制代码
• 序列化字符串（结合 pb 一起使用，最为广泛）
• set user:1 serialize(userinfo) 复制代码
• 优点：简单直观，每个属性都支持单独更新
• 缺点：占用过多的键，内存占用量大，同时用户信息内聚性差，盛昌环境比较少使用
• 哈希类型
• hmset user:1 name tom age 23 city shanghai 复制代码
• 优点：简化编程，合理运用序列化，可以提高内存的使用效率。
• 缺点：要控制在 ziplist 和 hashtable 两种内部编码的转换， hashtable 会消耗更多的内存

常见操作

作者：心城以北
链接：https://juejin.cn/post/7067946313735733284