
# 一、Hash类型说明
Redis Hash 就是 Redis 里的「对象 / Map 结构」，专门用来存**一个实体的多个字段**。
```请在此输入代码块语言
Hash Key：user:100
├── name  → 张三
├── age   → 28
├── phone → 13800138000
└── addr  → 北京
```
## Hash和字符串对比
| 类型 | 说明 | 多字段使用场景 |
| ------ | ------ | ------ | ------ | 
| String | 只能存 **一个 key 对应一个值** | 可以用Json，改一个字段必须整体序列化更新整个JSON查一个字段必须把整个JSON拿出来解析 | 
| Hash | **一个 key 里面，可以存多个 field-value 键值对** | 可以**单独改某个字段、单独查某个字段**，不用动整个对象 |




# 二、Hash类型使用方法

|Redis命令|作用|RedisTemplate方法|
|:-:|:-:|:-:|
|HSET|设置单个字段|opsForHash().put()|
|HMSET|批量设字段|opsForHash().putAll()|
|HGET|取单个字段|opsForHash().get()|
|HMGET|批量取字段|opsForHash().multiGet()|
|HGETALL|获取所有字段和值|opsForHash().entries()|
|HDEL|删除字段|opsForHash().delete()|
|HINCRBY|字段自增|opsForHash().increment()|
|HEXISTS|字段是否存在|opsForHash().hasKey()|
|HLEN|字段个数|opsForHash().size()|
## 2.1 命令行操作方式
#### 插入单个元素
语法：hset key field value
```bash
127.0.0.1:6379> hset hash key1 v1
(integer) 1
127.0.0.1:6379> hset hash key2 v2
(integer) 1
```
#### 当某键不存在时，插入数据
语法：hsetnx key field value
```bash
127.0.0.1:6379> hsetnx hash key1 v2
(integer) 0
127.0.0.1:6379> hsetnx hash key3 v1
(integer) 1
```
#### 查询单个元素
语法：hget key field
```bash
127.0.0.1:6379> hget hash key1
"v1"
```
#### 删除 key 中的一个或多个元素
语法：hget key field
```bash
127.0.0.1:6379> hdel hash 
```
#### 某个整数值累加计算
语法：hincrby key field increment
```bash
127.0.0.1:6379> hset hash key3 3
(integer) 0
127.0.0.1:6379> hincrby hash key1 5
(error) ERR hash value is not an integer
127.0.0.1:6379> hincrby hash key3 5
(integer) 8
```

## 2.2 代码操作方式

### Spring RedisTemplate
```java
@RequestMapping("/hash")
@ResponseBody
public Object hashAdd(@RequestParam(value = "num") Integer num) throws IOException {

    redisTemplate.opsForHash().put("hashKey", "test" , num);
    return (String) redisTemplate.opsForHash().get("hashKey","test");
}
```
### Jedis
```Java
 Jedis jedis = new Jedis("127.0.0.1", 6379);
 // 把 Key 值定义为变量        
 final String REDISKEY = "myhash";       
 // 插入单个元素       
 jedis.hset(REDISKEY, "key1", "value1");
 // 查询单个元素        
 Map<String, String> singleMap = jedis.hgetAll(REDISKEY);
 System.out.println(singleMap.get("key1"));  // 输出：value1
```

# 三、Hash类型底层结构
## 3.1 底层结构概述
Hash类型底层由压缩列表或者hash表实现的
在Redis 低版本的Hash，底层小数据使用ziplist，大数据为hashtable
在Redis 7.0+ 的 Hash，底层小数据用 listpack（取代 ziplist），大数据自动升级为 hashtable
![image.png](https://developer.qcloudimg.com/http-save/yehe-9980940/6a60cf51c23d47f57dc8182cad5c0a53.png)
## 3.2 什么场景下升级为hashtable
满足如下条件
hash字段数>N (N可配置）
任意value>M 字节（M可配置）
## 3.3 ziplist和listpack差异
参考：[Redis7.0代码分析：底层数据结构listpack实现原理](https://juejin.cn/post/7220950867339247653?searchId=202605142000524C114E8580896075FF36) 
[# Redis-结构篇-压缩列表](https://juejin.cn/post/6844904053579710478?searchId=202605142000524C114E8580896075FF36) 

### 3.3.1 压缩列表ziplist结构
ziplist 的最大特点，就是它被设计成一种内存紧凑型的数据结构，占用一块连续的内存空间，以达到节省内存的目的
虽然 ziplist 节省了内存开销，可它也存在两个设计代价：
一是不能保存过多的元素，否则访问性能会降低；
二是不能保存过大的元素，否则容易导致内存重新分配，甚至可能引发连锁更新的问题。
![image.png](https://developer.qcloudimg.com/http-save/yehe-9980940/ead402f02533a2583f95c0b9a7f3a62a.png)

#### (1)整体结构
| 属性 | 字节数 | 含义 | 
| ------ | ------ | ------ | 
| zlbytes | 4 | ziplist占用的内存总字节数：在对压缩列表进行内存重分配， 或者计算 zlend 的位置时使用 | 
| zltail | 4 | ziplist表最后一个节点的偏移量：用来倒序遍历压缩列表 | 
| zllen | 2 | 记录了压缩列表包含的节点数量： 当这个属性的值小于 UINT16_MAX （65535）时， 这个属性的值就是压缩列表包含节点的数量； 当这个值等于 UINT16_MAX 时， 节点的真实数量需要遍历整个压缩列表才能计算得出 | 
| entry[] | 待定 | 节点数组，包含元素的具体信息 | 
| zlend | 1 | 特殊值 0xFF （十进制 255 ），用于标记压缩列表的末端 | 

#### (2)单个节点结构
**prevlen**
prevlen 表示前一个元素的长度，以便能够从后向前遍历列表。它有一套特别的编码方式：如果这个长度小于254字节，那么它占用1个字节；当长度大于或等于254时，占用5个字节，第一个字节被设置为254 (0xFE)，其余的4个字节采用前一个条目的长度作为值。prevlen 用 5 bytes表示时，不代表长度一定大于等于254，这是为了减少 realloc 和 memmove 提高效率

**encoding**
encoding 表示元素的编码，它取决于元素的内容。当元素是一个字符串时，编码的第一个字节的前2位将保存用于存储字符串长度的编码类型，然后是字符串的实际长度。当条目是整数时，前2位都设置为1。下面的2位用于指定在这个报头之后将存储哪种类型的整数。

** data**
实际值
#### (3)ziplist两个问题
**查找中间元素复杂读高**
因为 ziplist 头尾元数据的大小是固定的，并且在 ziplist 头部记录了最后一个元素的位置，所以，当在 ziplist 中查找第一个或最后一个元素的时候，就可以很快找到
当要查找列表中间的元素时，ziplist 就得从列表头或列表尾遍历才行。而当 ziplist 保存的元素过多时，查找中间数据的复杂度就增加了。更糟糕的是，如果 ziplist 里面保存的是字符串，ziplist 在查找某个元素时，还需要逐一判断元素的每个字符，这样又进一步增加了复杂度。
**连锁更新风险**
连锁更新，就是 ziplist 中的每一项都要被重新分配内存空间，造成 ziplist 的性能降低。在 ziplist 中，每一个元素都会记录其**前一项的长度，也就是 prevlen**。
Redis 为了省内存，`prevlen` 分两种编码：
1. **情况 1**：前一个 entry 长度 **< 254 字节**
	- `prevlen` 只用 **1 字节** 存储
2. **情况 2**：前一个 entry 长度 **≥ 254 字节**
	- `prevlen` 要用 **5 字节** 存储

👉 **1 字节 ↔ 5 字节，长度变了，占用内存大小就变了**，这是连锁更新的根源。
所谓的**连锁更新**，就是指当一个元素插入后，会引起当前位置元素新增 prevlensize 的空间。而当前位置元素的空间增加后，又会进一步引起该元素的后续元素，其 prevlensize 所需空间的增加。
这样，一旦插入位置后续的所有元素，都会因为前序元素的 prevlenszie 增加，而引起自身空间也要增加，这种每个元素的空间都需要增加的现象，就是连锁更新
（前面某个节点的长度发生变化，导致它后面所有节点的 prevlen 都必须依次修改，一整片跟着动，这就叫 **连锁更新**）

### 3.3.2 listpack结构
listpack 也叫紧凑列表，它的特点就是**用一块连续的内存空间来紧凑地保存数据**，同时为了节省内存空间，**listpack 列表项使用了多种编码方式，来表示不同长度的数据**，这些数据包括整数和字符串
![image.png](https://developer.qcloudimg.com/http-save/yehe-9980940/37e59a3b14044f7b888cb69d5accebc2.png)

#### (1)整体结构
| 属性 | 字节数 | 含义 | 
| ------ | ------ | ------ | 
| total-bytes | 4 | listpack 总字节数 | 
| num-entries | 2 | listpack元素个数 | 
| entry[] | 待定 | 节点数组，包含元素的具体信息，不再存prevlen | 
| backlen | 1 | 当前 entry **自己的总长度**，放在末尾，用于反向遍历 | 
| end-byte | 1 | 结束标记 `0xFF` | 

#### (2)单个节点
 listpack entry

```
[encoding][data][backlen]
```
- **encoding 编码字段**
编码类型标识 `data` 是**整数**还是**字符串**，
标识数据长度，省去额外长度字段
Redis 做了大量数值压缩：小整数直接编码存储，不存字符串，极度省内存
- **data 真实数据**
业务原始内容：
数字：压缩编码存储
字符串：原始字节内容
- **backlen** 
编码类型+数据的总长度
**反向遍历**时，从后往前快速跳过当前元素，直接定位上一个元素
#### (3)listpack列表项的编码方法（即单个entry的encoding）
listpack 元素会对不同长度的整数和字符串进行编码
- 整数编码
    - 小整数LP_ENCODING_7BIT_UINT（0~127）——1 字节
     ![image.png](https://developer.qcloudimg.com/http-save/yehe-9980940/07b59c65a41e4af98b5cf1a96a79bc04.png)
    - 13 位有符号整数LP_ENCODING_13BIT_INT（-2048~2047）——2 字节
    - 16/24/32/64 位整数
    首字节固定：
   - LP_ENCODING_16BIT_INT → 16 位（2 字节数据）
  - LP_ENCODING_24BIT_INT → 32位（3 字节数据）
  -  LP_ENCODING_32BIT_INT → 16 位（4 字节数据）
  - LP_ENCODING_64BIT_INT → 16 位（8 字节数据）
- 字符串编码
   - 短字符串LP_ENCODING_6BIT_STR（0~63 字节）——1 字节头
   - 中字符串LP_ENCODING_12BIT_STR（0~4095）——2 字节头
   - 长字符串 LP_ENCODING_32BIT_STR（0~2³²-1）——5 字节头
   
![image.png](https://developer.qcloudimg.com/http-save/yehe-9980940/99a2b52f4f9a51e158b0b0548b99517f.png)
#### (4)listpack遍历
- **正向遍历**（从左向右遍历）
前 entry 起始位置 p：
  - 解析 encoding → 得知 data 长度
  - 跳过 encoding + data → 到达 backlen
  - 解析 backlen 的字节数（通过其编码规则自描述）
  - p = p + encoding_size + data_size + backlen_size → 下一个 entry

- **逆向遍历** （从右向左遍历）
  - 用 `总字节数 - 1` 定位到**最后一个元素的起始位置**（跳过结尾 0xFF）
  - 向前读取 backlen（backlen 的值 =  entry 的总字节数）到最后一个entry的头
  - p = p - backlen值 → 前一个 entry 的起始位置
### 3.3.3 ziplist和listpack对比
#### ziplist 的优点
- **内存高效**：通过连续存储和紧凑编码，ziplist 尽量减少内存浪费。
- **简单操作**：支持快速插入、删除和遍历（特别是正向遍历）。
#### ziplist 的缺点
- **连锁更新问题**：如果插入或修改一个条目导致它的长度变化，可能会触发后续条目的“前一个条目长度”字段更新，形成连锁反应，影响性能。
- **复杂性**：编码规则复杂，维护和扩展起来有一定难度。
- **遍历效率**：反向遍历需要依赖“前一个条目长度”，效率不如正向遍历。
由于这些问题，Redis 团队开发了 listpack 作为替代品。
#### listpack 的改进
- **消除了连锁更新**：listpack 记录的是当前条目的长度，而不是前一个条目的长度。因此，修改一个条目不会影响其他条目，避免了连锁更新问题。
- **更简单的编码**：listpack 的编码规则更统一，维护和扩展更方便。
- **更高的灵活性**：listpack 支持更高效的插入和删除操作，尤其在小型数据场景下。
#### listpack 的优点
- **更高的内存效率**：通过优化编码和结构，listpack 比 ziplist 更节省内存。
- **更好的性能**：消除了连锁更新，插入和修改操作更稳定。
- **更易维护**：代码更简洁，未来扩展更方便。

## 3.4 hashtable
```txt
RedisObject(外层Hash对象)     
└── encoding = hashtable     
└── ptr 指向 dict 结构体            
                ├── ht[0] 主哈希表             
	        ├── ht[1] 备用哈希表(rehash用)            
		└── rehashidx 渐进rehash标记
```

底层核心源码dictEntry 的结构
- `key`：对应 Hash 的 **field**
- `v`：对应 Hash 的 **field 对应 value**
- `next`：冲突链表指针，同哈希桶下挂链表
```c
typedef struct dictEntry { // dict.h   
     // Hash 里的 field
     void *key;    
    // Hash 里的 value
     union {         
          void *val;        
          uint64_t u64;         
          int64_t s64;         
          double d;    
          } v;    
          // 哈希冲突：指向下一个同桶节点（链表），即下一个 entry 
          struct dictEntry *next; 
} dictEntry;
```
![image.png](https://developer.qcloudimg.com/http-save/yehe-9980940/09efdd45c319766ff515ee880866e6db.png)

## 3.5 hash冲突与渐进式rehash
和Redis全局hash操作类似，[Redis怎么保存所有键值对的？——Redis系列(二)](https://cloud.tencent.com/developer/article/2669789) 




Redis Hash 就是 Redis 里的「对象 / Map 结构」，专门用来存一个实体的多个字段。

Redis的Hash类型数据结构——Redis系列(四)

后端

Redis Hash类型是专门用于存储对象/Map结构的高效数据结构，支持单独修改和查询字段，避免JSON整体序列化开销。底层采用listpack（小数据）和hashtable（大数据）实现，内存紧凑且避免连锁更新风险。通过HSET/HGET等命令可快速操作字段，适用于用户信息、商品属性等多字段存储场景，提升读写性能。

数据结构

大数据

Redis

JSON

Java

2026年中大促 | AI 领航 智绘未来

tcap

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Redis的Hash类型数据结构——Redis系列(四)-腾讯云开发者社区-腾讯云

Redis的Hash类型数据结构——Redis系列(四)

Redis的Hash类型数据结构——Redis系列(四)

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐