:数据结构Hash)
一、Hash 是什么？
逻辑层面
key = user:1 value = { name: "xiaolin", age: 18, city: "beijing" }也就是：
HSET user:1 name xiaolin age 18 city beijingHash 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) 修改
字段级原子操作
)
)