Redis哈希类型：高效存储与操作指南
几乎所有的主流编程语言都提供了哈希类型，它们的叫法可能是哈希、字典、关联数组、映射。在Redis中，哈希类型是指值本身又是一个键值对类型。
编辑
哈希类型中的映射关系通常称为Field-value，用于区分Redis整体的键值对key-value，注意这里的value是指Field对应的值，不是key对应的值。
命令
HSET
设置hash中的字段的值
HSET key field value 1 [field value ...]
时间复杂度：插入一组Field为O(1)，插入N组field为O(N)
返回值：添加字段的个数
举个🌰：
HGET
获取hash中指定的字段的值
语法：
HGET key field
时间复杂度：O(1)
返回值：字段对应的值或者nil
举个🌰：
HEXISTS
判断hash中是否有指定的字段
语法：
HEXISTS key field
时间复杂度:O(1)
返回值：1表示存在，0表示不存在
举个🌰：
HDEL
删除hash中指定的字段
语法：
HDEL key field [field ...]
时间复杂度：删除一个元素为O(1)，删除N个元素为O(N)
返回值：本次操作删除的字段的个数
举个🌰：
HKEYS
获取hash中的所有字段
语法：
HKEYS key
时间复杂度:O(N)，N为field的个数
返回值：字段列表
举个🌰：
HVALS
获取hash中的所有的值
语法:
HVALS key
时间复杂度：O(N)，N为field的个数
返回值：所有的值
举个🌰：
HGETALL
获取hash中的所有的字段以及其对应的值
语法：
HGETALL key
时间复杂度：O(N)，N为field的个数
返回值：字段和对应的值
举个🌰：
HMGET
一次获取hash中的多个字段的值
语法：
HMGET key field [field ...]
时间复杂度：只查询一个元素的时候是O(1)，查询多个元素为O(N)，N为查询元素的个数
返回值：字段对应的值或者nil
举个🌰：
在使用HGETALL的时候，如果hash元素的个数比较多，会存在阻塞Redis的可能。如果开发人员只需要获取部分的field，可以使用HMGET，如果一定要获取全部的field，可以尝试使用HCSAN命令，这个命令采用渐进式遍历哈希类型，后续介绍它
HLNE
获取hash中的所有字段的个数
语法：
HLEN key
时间复杂度：O(1)
返回值：字段的个数
举个🌰：
HSETNX
在字段不存在的情况下，设置hash中的字段和值
语法：
HSETNX key field value
时间复杂度：O(1)
返回值：1表示设置成功，0表示设置失败
举个🌰：
HINCRBY
将hash中的字段对应的值添加指定的值
语法：
HINCRBY 1 key field increment
时间复杂度：O(1)
返回值：该字段变化之后的值
举个🌰：
HINCRBYFLOAT
HINCRBY的浮点数版本
语法：
HINCRBYFLOAT 1 key field increment
时间复杂度：O(1)
返回值：该字段变化之后的值
举个🌰：
命令小结
| 命令 | 执行效果 | 时间复杂度 |
|---|---|---|
| hset key field value | 设置值 | O(1) |
| hget key field | 获取值 | O(1) |
| hdel key field [field ...] | 删除field | O(k),k是field的个数 |
| hlen key | 计算field的个数 | O(1) |
| hgetall key | 获取所有的field-value | O(k),k是field个数 |
| hmget field [field] | 批量获取field-value | O(k),k是filed个数 |
| hmset field value [field value ...] | 批量获取field-value | O(k),k是field个数 |
| hexists key field | 判断field是否存在 | O(1) |
| hkeys key | 获取所有的filed | O(k),k是field的个数 |
| hvals key | 获取所有的value | O(k),k是field的个数 |
| hsetnx key field value | 设置值，但必须在field不存在的时候才能设置成功 | O(1) |
| hincrby key field n | 对应field-value+n | O(1) |
| hincrbyfloat key field in | 对应field-value+n | O(1) |
| hstrlen key field | 对应value的字符长长度 | O(1) |
内部编码
哈希的内部编码有两种：
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字节的时候，内部编码会转换成hashtable
当 field 个数超过 512 时，内部编码也会转换为 hashtable：
使用场景
相比于使用JSON格式的字符创缓存用户信息，哈希类型变得更加直观，并且在更新操作上变得更灵活。可以将每个用户的ID定义为键后缀，多对field-value对应用户的各个属性。
但是需要注意的是哈希类型和关系型数据库有两点不同之处.
哈希类型是稀疏的，而关系型数据库是完全结构化的，例如哈希类型每个键可以有不同的 field，而关系型数据库一旦添加新的列，所有行都要为其设置值，即使为 null
关系数据库可以做复杂的关系查询，而 Redis 去模拟关系型复杂查询，例如联表查询、聚合查询等基本不可能，维护成本高
缓存方式对比
原生字符串类型 —— 使用字符串类型，每个属性一个键。
优点：实现简单，针对个别属性变更也很灵活
缺点：占用过多的键，内存占用量较大，同时用户信息在 Redis 中比较分散，缺少内聚性，所以这种方案基本没有实用性。
序列化字符串类型，例如 JSON 格式
优点：针对总是以整体作为操作的信息比较合适，编程也简单。同时，如果序列化方案选择合适，内存的使用效率很高。
缺点：本身序列化和反序列需要一定开销，同时如果总是操作个别属性则非常不灵活。
哈希类型
优点：简单、直观、灵活。尤其是针对信息的局部变更或者获取操作。
缺点：需要控制哈希在 ziplist 和 hashtable 两种内部编码的转换，可能会造成内存的较大消耗。