Redis(开发与运维):13---哈希对象

一、哈希对象简介

• 几乎所有的编程语言都提供了哈希（hash）类型，它们的叫法可能是哈希、字典、关联数组
• 在Redis中，哈希类型是指键值本身又是一个键值对结构，形如value={{field1，value1}，...{fieldN，valueN}}，Redis键值对和哈希类型二者的关系可以下图表示

• 一些特点：
  • 存储多个键值对之间的映射，并且键值对不允许重复
  • 在某一个固定的key中，其对应value中的field也不允许重复
  • 散列存储的值既可以是字符串也可以是数字值
  • 用户同样可以对散列存储的数字值执行自增操作或自减操作
  • 散列在很多方面是一个微缩版的Redis，不少字符串命令都有相应的散列版本
  • 熟悉文档数据库的读者可以将散列看作是文档数据库里面的文档，而熟悉关系数据库的读者可以将散列看作是关系数据库里面的行。因为“文档、行、散列”这三者都允许用户同时访问或修改一个或多个域
• 注意：哈希类型中的映射关系叫作field-value，注意这里的value是指field对应的值，不是键对应的值，请注意value在不同上下文的作用
• 关于哈希的设计与实现还可以参阅：https://blog.csdn.net/qq_41453285/article/details/103235100

二、命令

常用命令

• hset：设置值。如果设置成功会返回1，反之会返回0

hset key field value

• hsetnx：它们的关系就像set和setnx命令一样，只不过作用域由键变为field
• hget：获取值。如果键或field不存在，返回nil

hget key field

• hdel：删除field
  • hdel会删除一个或多个field，返回结果为成功删除field的个数
  • 直到某一个key对应的field全部删除完全之后，该哈希对象才会被删除

hdel key field [field ...]

• hlen：计算fileld个数

hlen key

• hmget、hmset：批量获取/设置field-value

hmget key field [field ...]
hmset key field value [field value ...]

• hstrlen：计算value的字符串长度（需要Redis3.2以上）

hstrlen key field

其他命令

• hincrby、hincrbyfloat：hincrby和hincrbyfloat，就像incrby和incrbyfloat命令一样，但是它们的作用域是filed
• hexists：判断field是否存在。field存在返回1，不包含返回0

• hkeys：获取所有field

hkeys key

• hvals：获取所有值

hvals key

• hgetall：获取所有的field-value

hgetall key

• 提示：在使用hgetall时，如果哈希元素个数比较多，会存在阻塞Redis的可能。 如果开发人员只需要获取部分field，可以使用hmget，如果一定要获取全部 field-value，可以使用hscan命令，该命令会渐进式遍历哈希类型，hscan可以参阅：https://blog.csdn.net/qq_41453285/article/details/106020231

• 下图给出了哈希类型命令的时间复杂度：

三、内部编码

• 哈希类型的内部编码有两种：
  • ziplist（压缩列表）：当哈希类型元素个数小于hash-max-ziplist-entries 配置（默认512个）、同时所有值都小于hash-max-ziplist-value配置（默认64 字节）时，Redis会使用ziplist作为哈希的内部实现，ziplist使用更加紧凑的 结构实现多个元素的连续存储，所以在节省内存方面比hashtable更加优秀
  • hashtable（哈希表）：当哈希类型无法满足ziplist的条件时，Redis会使 用hashtable作为哈希的内部实现，因为此时ziplist的读写效率会下降，而 hashtable的读写时间复杂度为O（1）

演示说明

• 当field个数比较少且没有大的value时，内部编码为ziplist：

• 当有value大于64字节，内部编码会由ziplist变为hashtable：

• 当field个数超过512，内部编码也会由ziplist变为hashtable

四、使用场景

• 下图为关系型数据表记录的两条用户信息，用户的属性作为表的列， 每条用户信息作为行

• 如果将其用哈希类型存储，如下图所示：

• 相比于使用字符串序列化缓存用户信息，哈希类型变得更加直观，并且在更新操作上会更加便捷。可以将每个用户的id定义为键后缀，多对fieldvalue对应每个用户的属性，类似如下伪代码：

UserInfo getUserInfo(long id){
    // 用户id作为key后缀
    userRedisKey = "user:info:" + id;
    // 使用hgetall获取所有用户信息映射关系
    userInfoMap = redis.hgetAll(userRedisKey);
    UserInfo userInfo;
    if (userInfoMap != null) {
        // 将映射关系转换为UserInfo
        userInfo = transferMapToUserInfo(userInfoMap);
    } else {
        // 从MySQL中获取用户信息
        userInfo = mysql.get(id);
        // 将userInfo变为映射关系使用hmset保存到Redis中
        redis.hmset(userRedisKey, transferUserInfoToMap(userInfo));
        // 添加过期时间
        redis.expire(userRedisKey, 3600);
    }
    return userInfo;
}

• 但是需要注意的是哈希类型和关系型数据库有两点不同之处：
  • 哈希类型是稀疏的，而关系型数据库是完全结构化的，例如哈希类型 每个键可以有不同的field，而关系型数据库一旦添加新的列，所有行都要为 其设置值（即使为NULL），如下图所示
  • 关系型数据库可以做复杂的关系查询，而Redis去模拟关系型复杂查询 开发困难，维护成本高

三种方案

• 开发人员需要将两者的特点搞清楚，才能在适合的场景使用适合的技术。到目前为止，我们已经能够用三种方法缓存用户信息，下面给出三种方案的实现方法和优缺点分析
• ①原生字符串类型：每个属性一个键
  • 优点：简单直观，每个属性都支持更新操作
  • 缺点：占用过多的键，内存占用量较大，同时用户信息内聚性比较差， 所以此种方案一般不会在生产环境使用

set user:1:name tom
set user:1:age 23
set user:1:city beijin

• ②序列化字符串类型：将用户信息序列化后用一个键保存。
  • 优点：简化编程，如果合理的使用序列化可以提高内存的使用效率
  • 缺点：序列化和反序列化有一定的开销，同时每次更新属性都需要把全 部数据取出进行反序列化，更新后再序列化到Redis中

set user:1 serialize(userInfo)

• ③哈希类型：每个用户属性使用一对field-value，但是只用一个键保存
  • 优点：简单直观，如果使用合理可以减少内存空间的使用
  • 缺点：要控制哈希在ziplist和hashtable两种内部编码的转换，hashtable会消耗更多内存

hmset user:1 name tomage 23 city beijing