深入学习 Redis - 深挖经典数据类型之 hash

青旅半醒 2024-03-17 22:30 101阅读 0赞

**目录**

前言

一、hash 类型

1.1、操作命令

hset / hget（设置 / 获取）

hexists（检查是否存在）

hdel（删除）

hkeys（获取所有 field）

hvals （获取所有的 value）

hgetall（获取所有键值对）

hmget（查询指定个 value）

hsetnx（设置值时设置参数）

hash 自增自减处理

1.2、hash 的内部编码方式

1.3、应用场景

缓存功能

什么是高内聚，低耦合?

--------------------

## 前言 ##

--------------------

redis 中所有的 key 都是字符串，value 的类型是存在差异的，因此出现了操控不同 value 的命令，接下来，就一起来学习一下吧~

> Ps1：接下来，我给出的指令都是按照 Redis 官方文档的语法格式来解析的，**\[ \] 相当于一个独立的单元，表示可选项（可有可无），其中 | 表示 “或者” 的意思，多个只能出现一个，\[ \] 和 \[ \] 之间是可以同时存在的.**

> Ps2：一个快速失去年终奖的小技巧 —— 清除 redis 上所有的数据 =》 FLUSHALL，这个操作可以把 redis 上所有的键值对全部带走.

##  ##

## 一、hash 类型 ##

--------------------

### 1.1、操作命令 ###

哈希表可以说是所有数据结构中最重要的，既是日常开发中最常用的，也是面试考察的重点.

Redis 自身已经是键值对结构了，但 value 实际上还是一些个键值对（哈希表）

#### hset / hget（设置 / 获取） ####

设置 hash 中指定的字段 field 和 value ，返回值是设置成功的键值对（field - value）的个数.

HSET key field value [field value ...]

获取 hash 中指定字段 field 的 value 值.

HGET key field

![ed35dc244fca482a938dec80558e9161.png][]

![708381053d914eff8d3c3854b5f48809.png][]

#### hexists（检查是否存在） ####

hexists 用来 hash 中检查字段 field 是否存在，返回 1 表示存在，返回 0 表示不存在.

HEXISTS key field

![1915a7a7df584e24812e1c133ae22d02.png][]

#### hdel（删除） ####

hdel 用来删除 hash 中指定的字段，返回值是本次操作删除的字段个数.

HDEL key field [field ...]

![0f2c84ea10b64a09b6519879e632e4fd.png][]

> Ps：del 删除的是 key，hdel 删除的是 field

#### hkeys（获取所有 field） ####

hkeys 用来获取指定 hash 的所有 field，返回值是所有的 field ，操作的时间复杂度为 O(N)，此处 N 为 hash 的元素个数.

HKEYS key

![b097ef7e28d0437cb5483c274f9c2c7c.png][]

> Ps：这个操作也是存在一定的风险的，类似与之前介绍过的 keys \*，主要是咱也不知道某个 hash 中是否存在大量的 field.

#### hvals （获取所有的 value） ####

和 hkeys 相对，能够获取到 hash 中所有的 value，操作的时间复杂度也是 O(N)，N 是 哈希 元素的个数，如果 哈希 非常大，也可能导致 redis 服务器阻塞.

HVALS key

![11e354b05d7e4b0e8da060a3c27288c8.png][]

#### hgetall（获取所有键值对） ####

获取指定 hash 中所有的键值对，一般不要在生产环境使用这个命令，因为你不知道这个 hash 中有多少键值对，就可能导致 redis 阻塞，最后带走你的年终奖~

HGETALL key

![18354d882d2540adba1d3a020fd01632.png][]

#### hmget（查询指定个 value） ####

通过 hash 可以根据指定个 field 查出相应的 value，类似于之前学习到的 mget .

HMGET key field [field ...]

![e2d7342bcf864f39ae83cb29b4d32a3e.png][]

hlen（查询个数）

用来查询 hash 的元素个数，这个操作不需要遍历，时间复杂度是 O(1).

HLEN key

![2053049334d24bbfa85d934ee8fc99d6.png][]

#### hsetnx（设置值时设置参数） ####

类似于 setnx，当 hash 的 field 不存在时，才能设置成功，若存在则不行.

返回 1 表示成功，返回 0 表示失败.

HSETNX key field value

![11666480f7cb4376b4f047d78dcc1f83.png][]

#### hash 自增自减处理 ####

hash 这里的 value 也可以当作数字来处理：

1.  hincrby：可以加减整数.
2.  hincrbyfloat：可以加减小数.

> 这些命令不经常使用，因此没有提供 incr decr... 这类命令.

### 1.2、hash 的内部编码方式 ###

hash 内部有两种编码方式：

1.  hashtable：最基本的哈希表（不是 java 标准库中的 HashTable），redis 内部对哈希表的实现方式和 java 中的哈希表可能不太一样，但是整体思想都是一样的；时间上复杂度O(1)，但是空间上会有一定的浪费（hash 是一个数组，数组上有些位置有元素，有些位置没有元素）.
2.  ziplist：压缩列表，当哈希表里的元素比较少的时候，就优化成了 ziplist 了，能够节省空间，但是读写元素的速度比较慢.

> ziplist 到底时怎么压缩的？

压缩的本质就是对数据进行重新编码，不同的数据有不同的特点，结合这些特点，重新编码后，就能够缩小体积~

例如 abbcccdddd 重新编码就变成了 1a2b3c4d.

再例如，有一个文件内容是：abcd0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000efgh

重新编码后就是 abcd\[100\]efgh.

ziplist 也是同理~

> 什么时候使用 ziplist？什么时候使用 hashtable？

1.  如果 hash 中的元素比较少，使用 ziplist 表示. 元素比较多的时候使用 hashtable 表示.
2.  每个 value 值的长度都比较短的，使用 ziplist 表示. 如果某个 value 长度太长，也会转化成 hashtable.

> 为什么我这里没有提到像“39”这样的具体数值？

因为这些数据类型内部转化的值都是需要根据实际工作情况而定的，他们都是再 redis.conf 文件中可以配置，满足一下任意一个就会发生转化，如下：

1.  hash-max-ziplist-entries（默认 512 个）：元素个数小于这个 配置值 后，转化为 ziplist.
2.  hash-max-ziplist-value（默认 64 字节）：所有 field 对应的 val 值都小于这个 配置值 后，转化为 ziplist.

### 1.3、应用场景 ###

#### 缓存功能 ####

hash 类型存储缓存相比于 string 类型就有更多的更合适的使用场景.

例如，我有以下这样一个 UserInfo 信息

![a11fc6aa3dc24f5cba31ef1b5b40fca4.png][]

> 假设这样一个场景就是：万一只想获取其中某一个 field ，或者修改某一个 field 的 val

如果使用 json 格式来表示 UserInfo ，就需要把数据组织成如下结构

set user:1:name James
    set user:1:age 23
    set user:1:city Beijing

就需要把整个 json 都读出来，解析成对象，操作field ，再转化成 json 字符串，再写回去.

但如果使用 hash 的方式来表示 UserInfo 就可以使用 field 表示对象的每一个属性（数据表的每一列），此时就可以很方便的获取属性的值了，如下结构

![d0c169b7e74744469739f9b802e437fb.png][]

这就相当于把每个用户的各个属性给聚集起来了，实现了高内聚~

#### 什么是高内聚，低耦合? ####

> **高内聚**，就是把所有关联的东西放在一起，最好能够放在指定的位置，好找~

讲个以前的故事：我小的时候有一个缺点，就是喜欢乱放东西，衣服经常会出现在很多地方，但唯独不会出现在衣柜，因此每次我要找某一个衣服的时候就很困难，因为需要把家里的各个角落都遍历一遍.

这种场景就是属于 低内聚 ~

> **耦合**，指的是 两个模块 / 代码 之间的关联关系，关联关系越大，越容易受影响，就认为耦合越大，而我们追求的是 低耦合 ，避免 “牵一发而动全身”，某一个地方出一个 bug，影响到了其他地方

讲个以前的故事：之前，有一次我爸得了肾结石，疼的满地打滚，后来就我去住院了，把那个结石取出来了，当时我妈为了照顾我爸，就推掉了当时工作的所有任务，请假来医院全程照顾我妈.

这种场景就输入 高耦合.

另外，当时在我微信里有一个不太熟悉的朋友（指网上认识的~）后来他发了个朋友圈，也是生病住院了，但我这边是不会有任何影响的，甚至还会给他的朋友圈点个赞 ~

这种场景就属于 低耦合.

![714cf8adf2594fa2afa34c9fb8d03158.gif][]

[ed35dc244fca482a938dec80558e9161.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/97ac6053cc10470e8f72fd03d7da75a9.png
[708381053d914eff8d3c3854b5f48809.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/cefc06e13c5d418587889ffa34fcd363.png
[1915a7a7df584e24812e1c133ae22d02.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e33ba945ce664aba8ad5553bd52828dc.png
[0f2c84ea10b64a09b6519879e632e4fd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/eaf175da89d44a8db36b9b305253d1d4.png
[b097ef7e28d0437cb5483c274f9c2c7c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/4604330e9bb44743b8be84e67983b3e6.png
[11e354b05d7e4b0e8da060a3c27288c8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/534161b9444445c4b773a714cbd963fb.png
[18354d882d2540adba1d3a020fd01632.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/29a4c2a5bb4a49d7b14a605e78bcfa27.png
[e2d7342bcf864f39ae83cb29b4d32a3e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/4ae24773e38e475694ca3e3f2e129cdf.png
[2053049334d24bbfa85d934ee8fc99d6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/85cdde5813734385b127bdc56a88b9e2.png
[11666480f7cb4376b4f047d78dcc1f83.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/07f147593d274e0d9c693bf53bf8510d.png
[a11fc6aa3dc24f5cba31ef1b5b40fca4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/a67264d7486a482c964d692a648aae6f.png
[d0c169b7e74744469739f9b802e437fb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/8469919c706d48329e60c051c470bc40.png
[714cf8adf2594fa2afa34c9fb8d03158.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/c5da34c8bc3a4f60906eeb0c6032047c.png