内部编码

哈希的内部编码有两种：

• ziplist（压缩列表）：当哈希类型元素个数⼩于hash-max-ziplist-entries配置（默认512个）、同时所有值都⼩于hash-max-ziplist-value配置（默认64字节）时，Redis会使⽤ziplist作为哈希的内部实现，ziplist使⽤更加紧凑的结构实现多个元素的连续存储，所以在节省内存⽅⾯⽐hashtable更加优秀
• hashtable（哈希表）：当哈希类型⽆法满⾜ziplist的条件时，Redis会使⽤hashtable作为哈希的内部实现，因为此时ziplist的读写效率会下降，⽽hashtable的读写时间复杂度为O(1)

---

测试内部编码：

1）当field个数⽐较少且没有⼤的value时，内部编码为ziplist：

2）当有value⼤于64字节时，内部编码会转换为hashtable：

3）当field个数超过512时，内部编码也会转换为hashtable：

---

使用场景

关系型数据表记录的两条⽤⼾信息，⽤⼾的属性表现为表的列，每条⽤⼾信息表现为⾏。如果映射关系表⽰这两个⽤⼾信息

使用关系型数据库表示用户的信息

若使用关系表映射用户的信息

相⽐于使⽤JSON格式的字符串缓存⽤⼾信息，哈希类型变得更加直观，并且在更新操作上变得更灵活。可以将每个⽤⼾的id定义为键后缀，多对field-value对应⽤⼾的各个属性，类似如下伪代码

UserInfo getUserInfo(long uid) {// 根据 uid 得到 Redis 的键String key = "user:" + uid;// 尝试从 Redis 中获取对应的值userInfoMap = Redis 执⾏命令：hgetall key;// 如果缓存命中（hit）if (value != null) {// 将映射关系还原为对象形式UserInfo userInfo = 利⽤映射关系构建对象(userInfoMap);return userInfo;}// 如果缓存未命中（miss）// 从数据库中，根据 uid 获取⽤⼾信息UserInfo userInfo = MySQL 执⾏ SQL：select * from user_info where uid = <uid>// 如果表中没有 uid 对应的⽤⼾信息if (userInfo == null) {响应 404return null;}// 将缓存以哈希类型保存Redis 执⾏命令：hmset key name userInfo.name age userInfo.age city userInfo.c// 写⼊缓存，为了防⽌数据腐烂（rot），设置过期时间为 1 ⼩时（3600 秒）Redis 执⾏命令：expire key 3600// 返回⽤⼾信息return userInfo;
}

需要注意的是哈希类型和关系型数据库有两点不同之处：

• 哈希类型是稀疏的，⽽关系型数据库是完全结构化的，例如哈希类型每个键可以有不同的field，⽽关系型数据库⼀旦添加新的列，所有⾏都要为其设置值，即使为null
• 关系数据库可以做复杂的关系查询，⽽Redis去模拟关系型复杂查询，例如联表查询、聚合查询等基本不可能，维护成本⾼

关系型数据库稀疏性

---

缓存方式对比

⽬前为⽌，我们已经能够⽤三种⽅法缓存⽤⼾信息（原生字符串类型，序列化字符串类型，哈希类型），下⾯给出三种⽅案的实现⽅法和优缺点分析

• 原⽣字符串类型⸺使⽤字符串类型，每个属性⼀个键

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

优点：实现简单，针对个别属性变更也很灵活。

缺点：占⽤过多的键，内存占⽤量较⼤，同时⽤⼾信息在Redis中⽐较分散，缺少内聚性，所以这种⽅案基本没有实⽤性。

• 序列化字符串类型，例如JSON格式

set user:1 经过序列化后的⽤⼾对象字符串

优点：针对总是以整体作为操作的信息⽐较合适，编程也简单。同时，如果序列化⽅案选择合适，内存的使⽤效率很⾼

缺点：本⾝序列化和反序列需要⼀定开销，同时如果总是操作个别属性则⾮常不灵活

• 哈希类型

hmset user:1 name James age 23 city Beijing 

优点：简单、直观、灵活。尤其是针对信息的局部变更或者获取操作。

缺点：需要控制哈希在ziplist和hashtable两种内部编码的转换，可能会造成内存的较⼤消耗

---