文章目录
- 内部编码
- 测试内部编码:
- 使用场景
- 缓存方式对比
内部编码
哈希的内部编码有两种:
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) {
响应 404
return 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
两种内部编码的转换,可能会造成内存的较⼤消耗