2023.12.25 关于 Redis 数据类型 Hash 常用命令、内部编码、应用场景

目录

Hash 数据类型

Hash 操作命令

HSET

HGET

HEXISTS

HDEL

HKEYS

HVALS

HGETALL

HMGET

HLEN

HSETNX

HINCRBY

HINCRBYFLOAT

HSTRLEN

Hash 编码方式

理解什么是压缩

Hash 实际应用

Cache 缓存

Hash 数据类型

• 整体上来说 Redis 是键值对结构，其中 key 和 value 之间通过哈希方式组织的
• 该结构中 key 负责组织数据的结构，而 value 却可以为不同类型的数据，其中一种类型就是 哈希
• 这就相当于在 value 中又存储了一层键值对（field - value），相当于所谓的套娃

---

实例理解

• 存储一个 uid 为 1 的用户对象，姓名为 mastermao 年龄为 20

注意：

• 当我们谈到 key ，指的是整体?Redis 键值对（key - value）结构中的 key?
• 当我们谈到 field，指的是 Redis 中的键值对对应的值（value）中哈希表中的一个特定的键
• 该特定键用来进一步区分 和 访问哈希表中的各个数据项

Hash 操作命令

HSET

• 用来设置 hash 中指定的字段 field 和 value
• 此处的（field - value）中的?value 只能为字符串类型

语法：

hset key field value [field value ...]

时间复杂度：

• O(1)

返回值：

• 返回值是设置成功的 键值对（field - value）的个数

?实例理解

---

HGET

• 用来获取 hash 中指定字段 field 的 value 值

语法：

hget key field

时间复杂度：

• O(1)

?实例理解

• 紧接着上述 hset 的实例进行测试

---

HEXISTS

• 用来检查 hash 中是否存在指定字段 field

语法：

hexists key field

时间复杂度：

• O(1)

返回值：

• 返回 1 表示存在
• 返回 0 表示不存在

实例理解

• 紧接着上述 hset 的实例进行测试

---

HDEL

• 用来删除 hash 中指定的字段 field

语法：

hdel key field [field ...]

时间复杂度：

• O（N）
• 其中 N 代表删除的字段个数，一般不会很大，也可认为是 O(1)

返回值：

• 本次操作删除的字段个数

实例理解

• 紧接着上述 hset 的实例进行测试

注意：

• del 删除的是 key
• hdel 删除的是 field

---

HKEYS

• 获取 hash 中的所有字段
• 该操作会现根据 key 找到对应的 hash，然后再遍历 hash

语法：

hkeys key

时间复杂度：

• O（N）
• 其中 N 为 field 的个数

实例理解

• hkeys key 命令存在一定的风险，类似于?keys * 命令
• 主要因为我们并不知道某个 hash 中是否存在大量的 field，从而导致 Redis 被阻塞?

---

HVALS

• 和上面的 hkeys 相对应，用于获取?hash 中的所有 value?

?语法：

hvals key

时间复杂度：

• O（N）
• 其中 N 为 field 的个数

?实例理解

注意：

• 使用 h 系列的命令操作 key 时，必须保证 key 对应的 value 得为?哈希 类型

---

HGETALL

• 用于获取 hash 中的所有字段 field 以及对应的值 value
• 相当于 hkeys + hvals 命令的结合

语法：

hgetall key

时间复杂度：

• O（N）
• 其中 N 为 field 的个数

?实例理解

• 观察此处的返回值
• 一个 field?一个 value 交替返回

注意：

• 上述操作风险比较大
• 因为多数情况下 不需要查询一个 key 中所有的 field 和 value 可能只查其中的几对

---

HMGET

• 用于获取 hash 中多个字段的值 value
• 类似于?mget 可以一次查询多个 key

?语法：

hmget key field [field ...]

时间复杂度：

• O（N）
• 其中 N 代表查询的字段个数，一般不会很大，也可认为是 O(1)

实例理解

注意：

• 此处 hmget 命令返回的值 value，与查询时 输入字段 field 的顺序相匹配

问题：

• 有没有 hmset 一次可以设置多对（field -?value）呢？

回答：

• 有 hmset 命令
• 但是并不需要使用其命令，因为 hset 已经支持一次设置多对（field -?value）了

---

小总结：

• 上述的 hkeys、hvals、hgetall 命令均存在一定风险
• 如果 hash 的元素个数太多，则执行的耗时会比较长，从而阻塞掉 Redis?

补充：

• hscan 命令可以渐进式地遍历 Redis 的 hash
• 即敲一次命令，遍历一小部分，再敲一次命令，再遍历一小部分
• 此时的时间是可控的，连续执行多次便可完成整个的 hash?的遍历，也就是所谓的 "化整为零"

---

HLEN

• 用于获取 hash 中的所有键值对个数

语法：

???????

hlen key

时间复杂度：

• O（1）
• 获取 hash 的元素个数不需要遍历

?实例理解

---

HSETNX

• 字段 field 不存在的情况下，设置 hash 中的字段 field 和 值 value
• 类似于 setnx????????

语法：

hsetnx key field value

时间复杂度：

• O（1）

返回值：

• 返回 1 表示设置成功
• 返回 0 表示设置失败

实例理解

---

HINCRBY

• hash 这里的 value 也可以被当作数字来进行处理
• hincrby 命令用来对 value 进行加减整数
• 因为使用频率不是特别高，Redis 没有提供 hincr、hdecr 之类的命令

?语法：

hincrby key field increment

时间复杂度：

• O（1）

返回值：

• value ± 之后的结果

实例理解

---

HINCRBYFLOAT

• hincybyfloat 命令用来对 value 进行加减小数

?语法：

hincrbyfloat key field increment

时间复杂度：

• O（1）

返回值：

• value ± 之后的结果

实例理解

---

HSTRLEN

• 用于计算 hash 中的值 value 的字符串长度

?语法:

hstrlen key field?

时间复杂度：

• O（1）

返回值：

• hash 中的值 value 的字符串长度，单位为字节

实例理解

Hash 编码方式

• 哈希的内部编码有 两种

1. ziplist 压缩列表
2. hashtable 哈希表

实例理解

• 我们通过 object encoding key 来查看编码方式

---

理解什么是压缩

• 压缩的本质，就是对数据进行重写编码
• 不同的数据有不同的特点
• 结合这些特点，进行精妙的设计，使其能够在重新编码之后，缩小体积

实例理解

• ' abbcccddddeeeee ' ———重新编码———> ' 1a2b3c4d5e '
• ' abcd0000000000000000000000000000000efgh ' ———重新编码———> 'abcd0[30]efgh??????? '

注意：

• 上述实例是比较粗糙的编码方式
• 实际上 一些常见的压缩算法都有着十分精妙的设计

• ziplist 也是同理，其内部的数据结构也进行了?精心设计，其目的就是为了节省内存空间

---

ziplist 和 hashtable

• 如果上来就直接使用 hashtable，那该哈希表中可能有些位置上有元素，有些位置上没有元素，从而会造成一定程度上的空间浪费
• 所以当一开始元素个数比较少时，还是先使用 ziplist 进行编码，以达到节省空间的目的
• 而 ziplist 作为一种内部编码方式，虽然一定程度上 节省了内存空间，但读写元素时的速度较慢
• 这种慢 在元素较少时可能不太明显，但是当元素数量过多时，性能下降会更为明显
• 相比之下 hashtable 的内部结构更为灵活，它可以更高效地处理大量的元素
• 在 hashtable 中，每个元素都通过哈希函数映射到不同的位置，这样在读写元素时可以更快地定位到目标位置

结论：

1. 哈希中的元素个数比较少，使用 ziplist 表示，元素个数比较多，使用 hashtable 来表示
2. 每个 value 的值长度都比较短，使用 ziplist 表示，如果某个 value 的长度太长了，也会转换成 hashtable

---

• hash-max-ziplist-entries 配置 （默认 512 个）???????
• hash-max-ziplist-value 配置（默认 64 字节）

理解：

• 这两个配置项是均可以写到 redis.conf 文件中
• 且两个配置的阈值是可变的，所以不用刻意的去 记背数值
• 因此我们需在不同的业务场景中，通过测试等相关的手段，来调整上述配置的阈值，以便找到一个更加合适的数值

Hash 实际应用

Cache 缓存

• 首先 String 类型是可以用作缓存的
• 但对于 存储结构化的数据，即类似于数据库 表 这样的结构，使用 hash 类型更适合一些

实例理解

• Redis 存储结构化的数据

方式一：

• 使用 hash 类型

注意：

• 此处的 key 中已经包含了 uid，那 hash 中?value?存储的 uid 是不是有点多此一举？
• 省去 hash 中?value 存储的 uid 是不是又可进一步节省存储空间？
• 首先如果确实不想在 hash 中?value 存储?uid 也可以省略掉
• 但是在工程实践中，通常会选择在哈希表的值 value 中再存储一份 uid
• 因为这样有助于简化代码逻辑，并使代码在后续开发中更为方便使用

方式二：

• 使用 string 类型?+ ?JSON 格式

set user:1 {"name": "mastermao", "age": 18, "city": "Changsha"}

注意：

• 使用 string 类型?+? JSON?格式来表示 userinfo 时
• 只想获取或修改其中的某个字段，就需要将整个 JSON 字符串读取出来
• 再解析成对象，进行字段操作，然后再将其转换回 JSON 字符串，并写回 Redis?
• 这样一系列过程相对繁琐

• 相较之下使用 hash 的方式来表示 userinfo?
• 可以使用字段 field 来表示对象的每个属性，类似于数据库 表 中的每个列
• 这样可以更方便地修改或获取任何一个属性的值
• 虽然 hash 的方式在读写字段 field 上更为直观、高效，但付出的代价是更大的存储空间需求
• 此外需要控制 哈希表 在 ziplist 和 hashtable 两种内部编码的转换，可能会导致较大的内存消耗

• 相比之下，使用 string 类型?+? JSON?格式的的内存消耗相对较小

方式三：

• 原生 String 类型，一个属性对应一个键
• 该方式相当于将同一个对象的各个属性 给分散开表示（低内聚）

set user:1:name mastermao
set user:1:age 18
set user:1:city Changsha

• ?????????????????????不建议使用该方式，该方式具有 低内聚性

---

理解高内聚低耦合

• 内聚就是将有关联的东西放到一起，最好能放到指定的地方，其优点为 好找
• 耦合就是两个模块 或 代码之间的关联关系，关联关系越大，越容易相互影响，则耦合也越大
• 我们追求低耦合，避免 "牵一发而动全身"，这边出一个?bug 同时也影响到了其他的地方

---

hash 类型 和 关系型数据库 的不同

1. 哈希类型是稀疏的，而关系型数据库是完全结构化的
2. ???????关系型数据库 可以做到复杂的查询，而 Redis 去模拟关系型复杂查询，例如联表查询、聚合查询等 基本不可能，维护成本高

实例理解

• 此处 哈希类型 每个键均有不同的字段?field
• 但关系型数据库 一旦添加新的列，其所有的行需为该列设置一个值，即便为 null???????

• 这就是为什么哈希类型是稀疏的，而关系型数据库是完全结构化的原因