详解redis(8):数据结构Hash

一、Hash 是什么？

逻辑层面

key = user:1 value = { name: "xiaolin", age: 18, city: "beijing" }

也就是：

HSET user:1 name xiaolin age 18 city beijing

Hash vs String

用 String 存对象

SET user:1 '{"name":"xiaolin","age":18}'

用 Hash 存对象

HSET user:1 name xiaolin age 18

对比点	String(JSON)	Hash
修改单个字段	❌ 需要整体改	✅
读取单字段	❌ 反序列化	✅
命令语义	弱	强
内存利用	一般	更优
适合对象	中	非常适合

二、为什么 Hash 特别适合存对象？

字段级操作

HINCRBY user:1 score 10

减少 Key 数量

不用：

user:1:name
user:1:age
user:1:city
而是：

user:1
Key 少，对 Redis 更友好

三、Hash 的内部实现

Redis 的哲学：小数据用紧凑结构，大数据用高效结构

两种底层结构

压缩列表

连续内存

紧凑存储

顺序查找

优缺点

内存占用极低
查找是 O(n)
插入删除可能引发连锁更新

哈希表

触发条件

字段多

或字段值大

特点

查找、更新 O(1)
指针多，内存占用高

Hash 自动转换机制

只升不降，不会再变回 ziplist

四、Redis 7.0 的变化：listpack

ziplist 的问题

连锁更新复杂

代码维护成本高

易产生性能抖动

listpack 是什么？

listpack 是 ziplist 的升级版

ziplist	listpack
头尾指针	❌
连锁更新	严重
结构复杂	高
维护成本	高

五、什么时候该用 Hash？

适合

用户信息

商品属性

配置项

状态对象

不适合

超大字段（几 MB）

只整体读写的对象（String 更简单）

六、Hash 实现购物车

为什么购物车是 Hash 的“天选场景”？

要素	对应 Hash
用户	key
商品	field
数量	value

为什么不用 List / String？

List

查商品要遍历

改数量不方便

不支持随机访问

String + JSON

改一个商品要整体反序列化

并发下容易冲突

Hash

O(1) 修改

字段级原子操作