做过 Redis 开发的同学肯定都遇到过 BigKey 问题：某个 Key 的 Value 太大，导致读取时阻塞主线程，整个 Redis 服务响应变慢甚至超时。我之前就遇到过这样一个案例：一个用户的购物车数据用单个 Hash 存储，随着时间推移数据越来越多，最终这个 Key 的 Value 达到了 15MB，每次读取都会导致 Redis 阻塞 500ms+，严重影响了系统性能。

今天我们就来聊聊 Redis BigKey 的危害，以及如何用 Hash 槽化迁移的方式实现零停机拆分。

BigKey 的危害

1. 什么是 BigKey

BigKey 定义：
- String 类型：Value 大小超过 1MB
- Hash/List/Set/ZSet：元素数量超过 1000 个

常见场景：
- 用户购物车：一个 Hash 存储所有商品
- 排行榜：一个 ZSet 存储所有用户分数
- 消息队列：一个 List 存储大量消息
- 配置中心：一个 String 存储超大配置

2. BigKey 的性能问题

性能影响分析：

1. 读取阻塞
   - GET bigkey → 一次性读取 10MB+ 数据
   - Redis 是单线程，阻塞期间无法处理其他请求
   - 响应时间从毫秒级变为秒级

2. 内存占用
   - 单个 Key 占用大量内存
   - 内存碎片问题严重
   - 影响 Redis 内存管理效率

3. 网络传输
   - 大数据量传输耗时
   - 占用大量带宽
   - 客户端接收缓冲区压力

4. 持久化问题
   - RDB/AOF 写入变慢
   - 备份文件过大
   - 恢复时间变长

5. 集群迁移问题
   - 槽位迁移时需要同步大量数据
   - 迁移期间可能超时
   - 影响集群稳定性

3. 典型案例分析

案例：购物车 Hash 表膨胀

初始设计：
- Key: cart:{userId}
- Value: Hash {itemId -> quantity}

问题发展：
- 用户 A 有 1000 件商品 → 10KB
- 用户 B 有 10000 件商品 → 100KB
- 某些用户有 100000+ 件商品 → 10MB+

性能表现：
- HGETALL cart:user123 → 500ms+
- 其他命令排队等待
- 服务超时率上升

解决方案：Hash 槽化迁移

1. 核心设计思想

槽化拆分策略：

原始结构：
┌─────────────────────────────────────────────┐
│ Key: cart:user123                           │
│ Value: { item1: 1, item2: 2, ..., itemN: N }│
└─────────────────────────────────────────────┘

槽化后结构：
┌─────────────────────────────────────────────┐
│ Key: cart:user123:0  → { item1, item2, ... }│
│ Key: cart:user123:1  → { item101, ... }     │
│ Key: cart:user123:2  → { item201, ... }     │
│ ...                                         │
│ Key: cart:user123:9  → { item901, ... }     │
└─────────────────────────────────────────────┘

拆分规则：
- 每个槽固定大小（如 100 个元素）
- 使用 CRC32(itemId) % 槽数 决定归属
- 槽数可配置（如 10 个槽）

2. 槽化算法设计

槽化路由算法伪代码：

function getSlotKey(userId, itemId, slotCount):
    # 计算 itemId 的哈希值
    hashValue = CRC32(itemId)
    
    # 确定槽位
    slotIndex = hashValue % slotCount
    
    # 返回槽化后的 Key
    return f"cart:{userId}:{slotIndex}"

# 示例：
# userId = 123, itemId = "item_456", slotCount = 10
# CRC32("item_456") = 123456789
# slotIndex = 123456789 % 10 = 9
# 返回: "cart:123:9"

3. 零停机迁移方案

迁移流程：

阶段一：双写（新老结构同时写入）
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  写入请求   │───→│  写入老Key  │    │  写入新槽位  │
│             │    │ (cart:user) │    │(cart:user:N)│
└─────────────┘    └─────────────┘    └─────────────┘

阶段二：数据同步（后台异步迁移）
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│ 后台迁移任务 │───→│ 读取老Key数据 │───→│ 写入新槽位  │
│             │    │ 分批读取    │    │ 分批写入    │
└─────────────┘    └─────────────┘    └─────────────┘

阶段三：切换读取（只读新结构）
┌─────────────┐    ┌─────────────┐
│  读取请求   │───→│  读取新槽位  │
│             │    │(cart:user:N)│
└─────────────┘    └─────────────┘

阶段四：清理旧数据
┌─────────────┐    ┌─────────────┐
│ 定时任务    │───→│ 删除老Key   │
│             │    │(cart:user)  │
└─────────────┘    └─────────────┘

4. 双写兼容层设计

双写兼容层伪代码：

class CartService:
    def __init__(self):
        self.slotCount = 10
        self.migrationComplete = False
    
    def addItem(self, userId, itemId, quantity):
        # 写入新槽位（始终执行）
        slotKey = self.getSlotKey(userId, itemId)
        redis.hset(slotKey, itemId, quantity)
        
        # 如果迁移未完成，同时写入老结构
        if not self.migrationComplete:
            oldKey = f"cart:{userId}"
            redis.hset(oldKey, itemId, quantity)
    
    def getItem(self, userId, itemId):
        # 如果迁移完成，只从新结构读取
        if self.migrationComplete:
            slotKey = self.getSlotKey(userId, itemId)
            return redis.hget(slotKey, itemId)
        
        # 迁移中：先查新结构，不存在再查老结构
        slotKey = self.getSlotKey(userId, itemId)
        value = redis.hget(slotKey, itemId)
        if value is not None:
            return value
        
        # 回退到老结构
        oldKey = f"cart:{userId}"
        return redis.hget(oldKey, itemId)
    
    def getSlotKey(self, userId, itemId):
        slotIndex = crc32(itemId) % self.slotCount
        return f"cart:{userId}:{slotIndex}"

迁移工具实现

1. 后台迁移任务

迁移任务伪代码：

function migrateBigKey(oldKey, slotCount):
    # 1. 获取老 Key 的类型
    type = redis.type(oldKey)
    
    # 2. 如果是 Hash 类型，分批扫描
    if type == "hash":
        cursor = 0
        totalMigrated = 0
        
        while cursor != 0 or totalMigrated == 0:
            # SCAN 分批获取，避免阻塞
            cursor, items = redis.hscan(oldKey, cursor, count=100)
            
            # 分批写入新槽位
            for itemId, value in items:
                userId = extractUserId(oldKey)
                slotKey = getSlotKey(userId, itemId, slotCount)
                
                # 使用 Pipeline 批量写入
                pipeline.hset(slotKey, itemId, value)
                
                totalMigrated += 1
            
            # 每批之后短暂休眠，避免占用太多资源
            time.sleep(0.01)
        
        log.info(f"迁移完成: {oldKey}, 共迁移 {totalMigrated} 条数据")
    
    # 3. 标记迁移完成
    markMigrationComplete(oldKey)

2. 数据一致性保证

一致性保障策略：

1. 写入顺序
   - 先写新结构，再写老结构
   - 新结构优先，保证读取时新数据优先

2. 读取兜底
   - 先读新结构，不存在再读老结构
   - 确保迁移过程中数据不丢失

3. 幂等性保障
   - 使用 Redis 的原子操作（HSET）
   - 重复写入不会造成数据错误

4. 监控告警
   - 监控迁移进度
   - 监控老结构写入次数（迁移完成后应为0）
   - 监控新老数据一致性

3. 渐进式迁移控制

渐进式迁移配置：

# 迁移速度控制
migration:
  batchSize: 100        # 每批处理数量
  sleepMs: 10           # 每批间隔（毫秒）
  maxConcurrency: 5     # 最大并发迁移任务数
  
# 阈值配置
threshold:
  bigKeySize: 10485760  # 10MB 触发自动迁移
  bigKeyCount: 10000    # 元素数量阈值
  
# 监控指标
metrics:
  migrationProgress: 0-100%
  remainingKeys: N
  estimatedTime: X minutes

实战方案

方案一：定时检测 + 自动迁移

自动检测流程：

1. 定时任务扫描所有 Key
2. 使用 DEBUG OBJECT 或 MEMORY USAGE 获取大小
3. 对超过阈值的 Key 标记为 BigKey
4. 自动触发迁移任务
5. 迁移完成后自动清理旧数据

方案二：手动标记 + 分批迁移

手动迁移流程：

1. 运维人员发现 BigKey
2. 在管理后台标记需要迁移的 Key
3. 选择迁移时间窗口（低峰期）
4. 启动迁移任务
5. 监控迁移进度
6. 验证数据一致性
7. 确认迁移完成

方案三：增量迁移 + 最终一致性

增量迁移流程：

1. 开启双写模式
2. 后台批量迁移历史数据
3. 实时监控写入比例
4. 当老结构写入比例低于阈值（如 1%）时
5. 停止双写，切换为只读新结构
6. 清理老结构数据

最佳实践

1. 事前预防

预防策略：

1. 设计阶段考虑
   - 避免使用单个 Key 存储大量数据
   - 提前规划槽化方案
   - 设置合理的数据结构大小限制

2. 监控预警
   - 监控 Key 的大小变化
   - 设置 BigKey 告警阈值
   - 定期生成 BigKey 报告

3. 限流保护
   - 对大 Key 操作设置时间限制
   - 使用异步方式处理大 Key 读取
   - 设置读取超时

2. 事中处理

处理原则：

1. 不要一次性读取整个 BigKey
   - 使用 HSCAN 替代 HGETALL
   - 使用 LRANGE 分批读取 List
   - 使用 ZSCAN 分批读取 ZSet

2. 避免在高峰期操作
   - 选择低峰期进行迁移
   - 设置迁移速度限制
   - 监控迁移对业务的影响

3. 确保迁移过程可回滚
   - 保留老结构直到验证完成
   - 设置回滚机制
   - 准备降级方案

3. 事后验证

验证清单：

1. 数据一致性验证
   - 对比新老结构的数据
   - 检查是否有遗漏或错误
   - 抽样验证数据正确性

2. 性能验证
   - 迁移后的响应时间
   - Redis 阻塞时间
   - 内存使用情况

3. 清理确认
   - 旧结构数据是否已删除
   - 迁移标记是否已更新
   - 监控指标是否正常

效果对比

总结

Redis BigKey 拆分的核心原则：

1. 预防胜于治疗：在设计阶段就避免产生 BigKey
2. 槽化拆分：使用 Hash 槽化将大数据量分散到多个 Key
3. 零停机迁移：通过双写、渐进式迁移实现无缝切换
4. 数据一致性：确保迁移过程中数据不丢失、不重复
5. 监控验证：迁移前后进行充分验证

记住：Redis 是单线程的，任何阻塞操作都会影响全局。合理设计数据结构，及时处理 BigKey，才能保证 Redis 服务的稳定性和高性能。

源码获取

文章已同步至小程序博客栏目，需要源码的请关注小程序博客。

公众号：服务端技术精选

小程序码：