11-Redis深度专题¶

┌──────────────────────────────────────────────────────────────────┐
│                     Redis 典型使用场景                            │
├──────────────┬───────────────────────────────────────────────────┤
│ 缓存         │ 数据库查询缓存、页面缓存、Session 缓存              │
│ 计数器       │ 文章阅读量、点赞数、在线人数                        │
│ 排行榜       │ 游戏排行、热搜排名（ZSet）                         │
│ 分布式锁     │ 秒杀、库存扣减、幂等性控制                          │
│ 消息队列     │ 异步任务处理、事件通知                               │
│ 限流         │ API限流、防刷、滑动窗口限流                         │
│ 社交关系     │ 共同好友、关注列表（Set交集）                        │
│ 地理位置     │ 附近的人、距离计算（GeoSpatial）                    │
│ 位图统计     │ 用户签到、在线状态（Bitmap）                        │
│ UV统计       │ 独立访客统计（HyperLogLog）                         │
│ AI/ML缓存    │ 特征缓存、模型推理结果缓存、embedding向量缓存        │
└──────────────┴───────────────────────────────────────────────────┘

# 基本操作
SET name "redis"              # 设置值
GET name                      # 获取值 → "redis"
SETNX lock:order "1"          # 不存在时才设置（分布式锁基础）
SETEX session:token 3600 "abc" # 设置带过期时间的值

# 计数器
INCR article:1001:views       # 自增 1
INCRBY article:1001:views 10  # 自增 10
DECR stock:sku123             # 自减 1

# 批量操作
MSET k1 v1 k2 v2 k3 v3       # 批量设置
MGET k1 k2 k3                # 批量获取

# 位操作（String底层也支持位操作）
SETBIT sign:user:1001:202601 5 1  # 用户1001在2026年1月第6天签到
GETBIT sign:user:1001:202601 5    # 查询是否签到 → 1
BITCOUNT sign:user:1001:202601    # 统计本月签到天数

Redis 3.2 之前：ziplist（压缩列表） + linkedlist（双向链表）
Redis 3.2 之后：quicklist（快速列表）= 双向链表 + ziplist 的组合
Redis 7.0 之后：quicklist = 双向链表 + listpack（替代 ziplist）

quicklist 结构示意：

head ←→ [ziplist1] ←→ [ziplist2] ←→ [ziplist3] ←→ tail
         ↑ entry     ↑ entry      ↑ entry
         ↑ entry     ↑ entry      ↑ entry
         ↑ entry

# 队列操作（FIFO）
LPUSH queue:task "task1" "task2" "task3"  # 左端入队
RPOP queue:task                           # 右端出队 → "task1"

# 栈操作（LIFO）
LPUSH stack:undo "action1" "action2"
LPOP stack:undo                           # → "action2"

# 阻塞弹出（消费者等待）
BRPOP queue:task 30                       # 阻塞30秒等待元素

# 范围查询
LRANGE mylist 0 -1                        # 获取所有元素
LRANGE mylist 0 9                         # 获取前10个元素
LLEN mylist                               # 获取长度

# 固定长度列表（最新N条消息）
LPUSH latest:news "news1"
LTRIM latest:news 0 99                    # 只保留最新100条

步骤：
1. 为 ht[1] 分配空间（扩容时为 ht[0].used * 2 的最小 2^n）
2. 设置 rehashidx = 0，标记 rehash 开始
3. 在每次对字典执行 CRUD 操作时，顺带将 ht[0] 中 rehashidx 索引上的所有键值对迁移到 ht[1]
4. rehashidx++
5. 当 ht[0] 全部迁移完成，将 ht[1] 设为 ht[0]，释放旧表

期间：
- 查找/删除/更新：先查 ht[0]，再查 ht[1]
- 新增：只写入 ht[1]（保证 ht[0] 只减不增）

# 存储对象
HSET user:1001 name "张三" age 25 city "北京"
HGET user:1001 name              # → "张三"
HMGET user:1001 name age city    # 批量获取
HGETALL user:1001                # 获取所有字段

# 计数（适合统计场景）
HINCRBY user:1001 login_count 1  # 登录次数+1

# 判断字段是否存在
HEXISTS user:1001 email          # → 0（不存在）

# 获取所有字段名/值
HKEYS user:1001                  # → ["name", "age", "city"]
HVALS user:1001                  # → ["张三", "25", "北京"]

# 基本操作
SADD tags:article:1001 "Redis" "数据库" "缓存"
SMEMBERS tags:article:1001      # 获取所有成员
SISMEMBER tags:article:1001 "Redis"  # 判断是否存在 → 1
SCARD tags:article:1001         # 获取成员数 → 3

# 社交关系：共同关注
SADD follow:user:A "user1" "user2" "user3"
SADD follow:user:B "user2" "user3" "user4"
SINTER follow:user:A follow:user:B    # 交集 → "user2" "user3"
SUNION follow:user:A follow:user:B    # 并集
SDIFF follow:user:A follow:user:B     # A有B没有的 → "user1"

# 随机元素（抽奖场景）
SRANDMEMBER lottery:pool 3      # 随机抽3个（不删除）
SPOP lottery:pool 1             # 随机弹出1个（删除）

Level 3:  1 ──────────────────────────────→ 9
Level 2:  1 ──────────→ 5 ────────────────→ 9
Level 1:  1 ───→ 3 ───→ 5 ───→ 7 ────────→ 9
Level 0:  1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9  (原始链表)

# 排行榜
ZADD leaderboard 98.5 "player:A" 95.0 "player:B" 99.0 "player:C"

# 获取排名（从高到低）
ZREVRANK leaderboard "player:C"        # → 0（第1名）
ZREVRANGE leaderboard 0 9 WITHSCORES   # Top 10 及分数

# 获取分数
ZSCORE leaderboard "player:A"          # → 98.5

# 分数范围查询
ZRANGEBYSCORE leaderboard 90 100       # 90-100分的成员
ZCOUNT leaderboard 90 100              # 90-100分的成员数

# 增加分数
ZINCRBY leaderboard 2.5 "player:B"     # B加2.5分

# 集合运算（加权排行汇总）
ZUNIONSTORE total:rank 2 rank:math rank:english WEIGHTS 0.6 0.4

# 用户1001在2026年1月的签到记录
# 第1天签到
SETBIT sign:1001:202601 0 1
# 第3天签到
SETBIT sign:1001:202601 2 1
# 第5天签到
SETBIT sign:1001:202601 4 1

# 查询第3天是否签到
GETBIT sign:1001:202601 2     # → 1

# 统计本月签到天数
BITCOUNT sign:1001:202601     # → 3

# 查询本月首次签到位置
BITPOS sign:1001:202601 1     # → 0（第1天）

# 多天签到统计（AND运算：连续签到）
BITOP AND result sign:1001:202601 sign:1001:202602

# 记录页面访问
PFADD page:index:uv "user1" "user2" "user3" "user1"  # user1重复
PFCOUNT page:index:uv                                  # → 3（去重后）

# 合并多个页面的UV
PFADD page:about:uv "user2" "user4"
PFMERGE total:uv page:index:uv page:about:uv
PFCOUNT total:uv                                       # → 4

# 添加地理位置
GEOADD shops 116.403963 39.915119 "北京烤鸭店"
GEOADD shops 116.413413 39.908692 "火锅店"
GEOADD shops 121.472644 31.231706 "上海小笼包"

# 查看位置
GEOPOS shops "北京烤鸭店"

# 计算两点距离
GEODIST shops "北京烤鸭店" "火锅店" km   # → ~1.2 km

# 搜索附近门店（以某坐标为圆心，5km半径）
GEOSEARCH shops FROMLONLAT 116.403963 39.915119 BYRADIUS 5 km ASC COUNT 10

# 生产者：发送消息
XADD stream:orders * user_id 1001 product_id "SKU123" amount 2

# 消费者：读取消息
XREAD COUNT 10 BLOCK 5000 STREAMS stream:orders 0
# BLOCK 5000: 阻塞5秒等待新消息

# 创建消费者组
XGROUP CREATE stream:orders group1 0

# 消费者组消费（不同消费者读取不同消息）
XREADGROUP GROUP group1 consumer1 COUNT 5 BLOCK 2000 STREAMS stream:orders >
XREADGROUP GROUP group1 consumer2 COUNT 5 BLOCK 2000 STREAMS stream:orders >

# 确认消息已处理
XACK stream:orders group1 "1624000000000-0"

# 查看待处理消息（消费者crash后可重新处理）
XPENDING stream:orders group1 - + 10

# 方式1：手动触发（阻塞主线程，生产环境禁用）
SAVE

# 方式2：手动触发（fork子进程执行，推荐）
BGSAVE

# 方式3：自动触发（redis.conf 配置）
# save 900 1      # 900秒内至少1次修改
# save 300 10     # 300秒内至少10次修改
# save 60 10000   # 60秒内至少10000次修改

1. 主进程调用 fork() 创建子进程
2. fork 使用 Copy-On-Write（写时复制）机制：
   - 子进程与父进程共享内存页
   - 只有当父进程修改某个内存页时，才会复制该页
3. 子进程遍历所有数据，写入 RDB 文件
4. 子进程完成后，用新 RDB 文件替换旧文件

                 ┌──────────────────────┐
                 │      主进程           │
                 │  继续处理客户端请求    │
                 └──────┬───────────────┘
                        │ fork()
                 ┌──────▼───────────────┐
                 │      子进程           │
                 │  遍历内存 → dump.rdb  │
                 │  （Copy-On-Write）    │
                 └──────────────────────┘

┌──────────────┬──────────────────────────────────┬────────────────────┐
│ 策略          │ 说明                              │ 数据安全性          │
├──────────────┼──────────────────────────────────┼────────────────────┤
│ always       │ 每条命令都 fsync 到磁盘             │ 最安全，最多丢1条    │
│ everysec     │ 每秒 fsync 一次（推荐）             │ 最多丢1秒数据        │
│ no           │ 由操作系统决定何时 fsync            │ 性能最好，可能丢较多  │
└──────────────┴──────────────────────────────────┴────────────────────┘

# 重写前（AOF文件记录了多次操作）：
SET name "A"
SET name "B"
SET name "C"
INCR counter
INCR counter
INCR counter

# 重写后（等效的最少命令）：
SET name "C"
SET counter 3

开启方式：
aof-use-rdb-preamble yes

原理：
AOF 重写时，文件前半部分是 RDB 格式（全量数据快照），
后半部分是 AOF 格式（重写期间的增量命令）。

┌─────────────────────────────────────┐
│          混合持久化 AOF 文件          │
├─────────────────────┬───────────────┤
│   RDB 格式数据      │  AOF 增量命令  │
│  （快速加载全量）    │ （追加增量）    │
└─────────────────────┴───────────────┘

优势：
- 加载速度接近纯 RDB（快）
- 数据安全性接近纯 AOF（丢失少）

写请求 → [Master] ──同步──→ [Slave 1] ← 读请求
                  ──同步──→ [Slave 2] ← 读请求
                  ──同步──→ [Slave 3] ← 读请求

1. Slave 发送 PSYNC ? -1（首次请求全量同步）
2. Master 执行 BGSAVE 生成 RDB
3. Master 将 RDB 发送给 Slave
4. 生成 RDB 期间的写命令存入 repl_backlog_buffer
5. Slave 加载 RDB
6. Master 将 repl_backlog_buffer 中的命令发送给 Slave
7. 后续进入增量同步

- Master 的写命令实时传播给 Slave
- 使用 repl_backlog_buffer（环形缓冲区）记录最近的写命令
- Slave 断线重连后，通过 offset 判断是否可以增量同步
- 如果 offset 还在 buffer 内 → 增量同步（发送差量数据）
- 如果 offset 已超出 buffer → 全量同步（重新 RDB）

建议：适当调大 repl-backlog-size（默认1MB → 建议64MB-256MB）

           ┌────────────┐
           │ Sentinel 1 │
           └─────┬──────┘
                 │ 监控
 ┌───────────────┼───────────────┐
 │               │               │
 ▼               ▼               ▼
[Master]     [Slave 1]      [Slave 2]
                 │
          自动故障转移
                 │
                 ▼
          [New Master]

1. 发现 Master 客观下线的 Sentinel 发起选举
2. 向其他 Sentinel 请求投票（RequestVote）
3. 每个 Sentinel 在每个 epoch 只投一票（先到先得）
4. 获得多数票（> N/2 + 1）的 Sentinel 成为 Leader
5. Leader 执行故障转移

1. Leader Sentinel 从所有 Slave 中选择新 Master：
   - 排除已下线的 Slave
   - 选择 slave-priority 最小的（优先级最高）
   - 选择 offset 最大的（数据最新）
   - 选择 run_id 最小的（启动最早）
2. 向选出的 Slave 发送 SLAVEOF NO ONE（升级为 Master）
3. 向其他 Slave 发送 SLAVEOF 新Master（切换复制目标）
4. 继续监控旧 Master，恢复后设为 Slave

Redis Cluster 将整个数据空间划分为 16384 个哈希槽（slot）。
每个 key 通过 CRC16(key) % 16384 确定所属槽。
每个节点负责一部分槽。

示例（3主3从）：
┌──────────────────────────────────────────────────────────────┐
│  Node A (Master)     Node B (Master)     Node C (Master)    │
│  Slot: 0-5460        Slot: 5461-10922    Slot: 10923-16383  │
│       │                    │                    │           │
│  Node A' (Slave)     Node B' (Slave)     Node C' (Slave)    │
└──────────────────────────────────────────────────────────────┘

为什么是 16384？
- 16384 = 2^14，CRC16 结果为 16 位，取模 16384 等价于取低14位
- 心跳包中 bitmap 大小为 16384/8 = 2KB，网络带宽友好
- 集群规模最多约1000个节点，16384个槽够用

- 每个节点维护集群状态（节点信息、槽分配）
- 节点间通过 Gossip 协议交换状态（PING/PONG消息）
- 每次 PING/PONG 携带自身信息 + 随机几个其他节点信息
- 优点：去中心化，容错性强
- 缺点：状态收敛需要时间（最终一致性）

客户端请求的 key 不在当前节点时：

MOVED 重定向（永久转移）：
  → 说明该槽已经永久迁移到目标节点
  → 客户端更新本地槽映射表，后续直接请求目标节点

ASK 重定向（临时转移，迁移中）：
  → 说明该槽正在从源节点迁移到目标节点
  → 客户端本次请求到目标节点（先发 ASKING 命令），但不更新映射表
  → 下次请求仍发到源节点

┌──────────────────────┬───────────────────────────────────────────────┐
│ 策略                  │ 说明                                         │
├──────────────────────┼───────────────────────────────────────────────┤
│ noeviction           │ 不删除，内存满时写操作返回错误（默认）           │
│ allkeys-lru          │ 从所有key中淘汰最近最少使用的（推荐）           │
│ volatile-lru         │ 从设置了过期时间的key中淘汰LRU                 │
│ allkeys-lfu          │ 从所有key中淘汰最不经常使用的（Redis 4.0+）    │
│ volatile-lfu         │ 从设置了过期时间的key中淘汰LFU                 │
│ allkeys-random       │ 从所有key中随机淘汰                           │
│ volatile-random      │ 从设置了过期时间的key中随机淘汰                │
│ volatile-ttl         │ 淘汰剩余TTL最短的key                          │
└──────────────────────┴───────────────────────────────────────────────┘

# 查看 key 的 LRU/LFU 信息
OBJECT FREQ mykey           # LFU频率
OBJECT IDLETIME mykey       # LRU空闲时间（秒）

# 配置淘汰策略
CONFIG SET maxmemory 4gb
CONFIG SET maxmemory-policy allkeys-lfu

# 基本事务
MULTI                       # 开启事务
SET account:A 1000
SET account:B 2000
EXEC                        # 执行事务（所有命令原子执行）

# 放弃事务
MULTI
SET key1 "value1"
DISCARD                     # 取消事务

# WATCH 乐观锁（CAS）
WATCH account:A             # 监视 key
balance = GET account:A     # 获取当前值
MULTI
SET account:A (balance - 100)
EXEC                        # 如果 account:A 在 WATCH 后被其他客户端修改，EXEC 返回 nil

# EVAL 执行 Lua 脚本
# 语法：EVAL script numkeys key1 key2 ... arg1 arg2 ...
EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey myvalue

# 库存扣减（原子操作）
EVAL "
    local stock = tonumber(redis.call('GET', KEYS[1]))
    if stock > 0 then
        redis.call('DECR', KEYS[1])
        return 1
    end
    return 0
" 1 stock:sku123

# EVALSHA（缓存脚本，减少网络传输）
# 先用 SCRIPT LOAD 缓存脚本，获得 SHA1
SCRIPT LOAD "return redis.call('GET', KEYS[1])"
# → "a42059b356c875f0717db19a51f6aaa9161571a2"
EVALSHA "a42059b356c875f0717db19a51f6aaa9161571a2" 1 mykey

# 订阅者（终端1）
SUBSCRIBE channel:news        # 订阅频道
PSUBSCRIBE channel:*          # 模式订阅（通配符）

# 发布者（终端2）
PUBLISH channel:news "Breaking: Redis 8.0 released!"

# 查看活跃频道
PUBSUB CHANNELS
PUBSUB NUMSUB channel:news   # 查看频道订阅数

# 配置慢查询
CONFIG SET slowlog-log-slower-than 10000  # 超过10ms记录（单位微秒）
CONFIG SET slowlog-max-len 128             # 最多保存128条

# 查看慢查询记录
SLOWLOG GET 10        # 获取最近10条慢查询
SLOWLOG LEN           # 当前慢查询条数
SLOWLOG RESET         # 清空慢查询日志

# 慢查询记录包含：
# 1) 日志ID  2) 发生时间戳  3) 耗时(微秒)  4) 命令及参数

# 错误：两条命令不是原子操作（SETNX成功后崩溃，EXPIRE未执行 → 死锁）
SETNX lock:order 1
EXPIRE lock:order 30

# 正确：使用 SET 命令的 NX 和 EX 选项（原子操作）
SET lock:order "request_id_123" NX EX 30
# NX: 不存在时才设置
# EX 30: 过期时间30秒

# Lua 脚本原子地判断并删除
EVAL "
    if redis.call('GET', KEYS[1]) == ARGV[1] then
        return redis.call('DEL', KEYS[1])
    end
    return 0
" 1 lock:order "request_id_123"

步骤：
1. 获取当前时间戳 T1
2. 依次向 N 个独立 Redis 实例请求加锁（SET NX EX）
3. 如果在超过 N/2+1 个实例上加锁成功，且总耗时 < 锁过期时间
   → 加锁成功，实际有效时间 = 过期时间 - 加锁耗时
4. 否则，向所有实例释放锁

争议（Martin Kleppmann vs Antirez）：
- 反对：依赖系统时钟同步、存在分布式系统time jump问题
- 支持：在大多数实际场景下足够可靠
- 结论：如果需要强一致性，建议使用 ZooKeeper 或 etcd

读流程：
1. 先读缓存 → 命中则返回
2. 缓存未命中 → 读数据库 → 写入缓存 → 返回

写流程：
1. 先更新数据库
2. 再删除缓存（而不是更新缓存！）

为什么是"删除"缓存而不是"更新"？
- 避免并发写导致的缓存与DB不一致
- 缓存值可能是复杂计算结果，每次更新代价高
- 懒加载思想：下次读取时再重建缓存

应用程序只与缓存交互，缓存层负责与数据库同步。

Read Through：
  应用 → 缓存（未命中 → 缓存自动从DB加载）→ 返回数据

Write Through：
  应用 → 缓存（同步写入DB，确认后返回）→ 写入完成

优点：应用逻辑简单
缺点：缓存层实现复杂，写延迟高（同步写DB）

写操作只更新缓存，异步批量写入数据库。

应用 → 缓存（立即返回）
         ↓ 异步/批量
        数据库

优点：写性能极高
缺点：数据一致性差，缓存崩溃可能丢数据
适用：写密集且允许短暂不一致的场景（如日志、计数）

# 查询 DB，结果为空
# → 缓存空值，设置较短过期时间
SET user:99999 "" EX 300    # 缓存空值5分钟

原理：
1. 用一个位数组（bitmap）+ 多个哈希函数
2. 添加元素时，用多个哈希函数计算位置，将对应位设为1
3. 查询时，如果所有哈希位置都为1 → 可能存在（误判率约1%）
4. 如果任何位置为0 → 一定不存在

请求 → BloomFilter 判断 key 是否存在
  → 不存在：直接返回（拦截）
  → 可能存在：查缓存 → 查数据库

# 每分钟限制100次请求
SET rate:api:user1001 0 EX 60 NX   # 不存在时初始化
INCR rate:api:user1001              # 每次请求+1
# 如果结果 > 100，拒绝请求

-- 令牌桶限流 Lua 脚本
-- KEYS[1]: 令牌桶key
-- ARGV[1]: 桶容量(burst)
-- ARGV[2]: 令牌生成速率(每秒)
-- ARGV[3]: 当前时间戳

local key = KEYS[1]
local capacity = tonumber(ARGV[1])     -- 桶容量
local rate = tonumber(ARGV[2])          -- 令牌/秒
local now = tonumber(ARGV[3])

local last_time = tonumber(redis.call('hget', key, 'last_time') or now)
local tokens = tonumber(redis.call('hget', key, 'tokens') or capacity)

-- 计算新增令牌
local elapsed = math.max(0, now - last_time)
tokens = math.min(capacity, tokens + elapsed * rate)

if tokens >= 1 then
    tokens = tokens - 1
    redis.call('hset', key, 'tokens', tokens)
    redis.call('hset', key, 'last_time', now)
    redis.call('expire', key, capacity / rate * 2)
    return 1  -- 允许
else
    redis.call('hset', key, 'last_time', now)
    return 0  -- 拒绝
end

# 游戏排行榜
ZADD game:leaderboard 1500 "player:A"
ZADD game:leaderboard 2300 "player:B"
ZADD game:leaderboard 1800 "player:C"
ZADD game:leaderboard 2100 "player:D"

# Top 3（分数从高到低）
ZREVRANGE game:leaderboard 0 2 WITHSCORES
# → "player:B" 2300, "player:D" 2100, "player:C" 1800

# 查看某玩家排名
ZREVRANK game:leaderboard "player:A"   # → 3（第4名，0-based）

# 增加分数
ZINCRBY game:leaderboard 500 "player:A"  # A加500分

# 获取某分数段的玩家
ZRANGEBYSCORE game:leaderboard 2000 3000

# 分页查询（第2页，每页10个）
ZREVRANGE game:leaderboard 10 19 WITHSCORES

秒杀架构：

用户请求 → Nginx限流 → 网关层 → 秒杀服务 → Redis预扣库存 → MQ异步下单 → 数据库

Redis在秒杀中的角色：
1. 商品库存预热：提前将库存加载到Redis
2. 原子扣减库存：Lua脚本保证原子性
3. 用户去重：Set防止重复下单
4. 限流控制：滑动窗口限流

-- 秒杀扣库存 Lua 脚本（原子操作）
-- KEYS[1]: 库存key  KEYS[2]: 订单集合key
-- ARGV[1]: 用户ID

-- 1. 检查用户是否已下单
if redis.call('sismember', KEYS[2], ARGV[1]) == 1 then
    return -1  -- 重复下单
end

-- 2. 检查库存
local stock = tonumber(redis.call('get', KEYS[1]))
if stock <= 0 then
    return 0  -- 库存不足
end

-- 3. 扣减库存
redis.call('decr', KEYS[1])
-- 4. 记录已下单用户
redis.call('sadd', KEYS[2], ARGV[1])
return 1  -- 下单成功，后续异步处理

# ❌ 错误：DEL（同步阻塞，大Key可能阻塞数秒）
DEL big:hash:key

# ✅ 正确：UNLINK（异步删除，Redis 4.0+）
UNLINK big:hash:key
# 后台线程异步释放内存，不阻塞主线程

# 对于 Hash/Set 等：分批删除
# HSCAN + HDEL 分批删除大Hash
HSCAN big:hash:key 0 COUNT 100
HDEL big:hash:key field1 field2 ... field100
# 循环直到删完

# 大Hash拆分：按field分片
# 原始：user:profile → 包含100个field
# 拆分：user:profile:0, user:profile:1, ...
# 分片规则：field_hash = CRC32(field) % N

# 大List拆分：按范围分段
# 原始：timeline:user1 → 100万条
# 拆分：timeline:user1:0, timeline:user1:1, ...（每段5000条）

方案1：本地缓存（JVM缓存 / Python dict）
  → 热点数据在应用层缓存，减少 Redis 请求
  → 使用 Caffeine/Guava（Java）或 cachetools（Python）
  → 设置较短的本地缓存TTL（如10秒）

方案2：读写分离 + 读副本
  → 多个只读从节点分担读压力
  → 客户端随机选择从节点读取

方案3：Key 分片
  → 将 hot:key 拆分为 hot:key:0, hot:key:1, ..., hot:key:N
  → 读取时随机选择一个分片
  → 写入时更新所有分片（或通过消息队列异步同步）

# 1. 合理使用数据类型（利用小数据类型的压缩编码）
# Hash 元素少时用 ziplist（内存比hashtable省很多）
CONFIG SET hash-max-ziplist-entries 128
CONFIG SET hash-max-ziplist-value 64

# 2. 控制 Key 的过期时间（避免大量永不过期的Key堆积）
SET session:user:1001 "data" EX 1800  # 30分钟过期

# 3. 内存碎片整理（Redis 4.0+）
CONFIG SET activedefrag yes        # 开启自动碎片整理
# 查看碎片率
INFO memory
# mem_fragmentation_ratio > 1.5 时建议整理

# 4. 使用更紧凑的编码
# 用 Hash 替代多个 String 存储对象属性（一个 Hash ziplist 比多个 String 省内存）

# 5. 监控内存使用
INFO memory                        # 查看整体内存信息
MEMORY DOCTOR                      # Redis内存诊断
MEMORY STATS                       # 详细内存统计