Redis on 纪伟的个人博客

Redis 学习笔记（四）：持久化与高可用

Wed, 03 Jun 2026 10:00:00 +0800

写在前面

本文是 Redis 学习笔记系列的最后一篇，介绍 Redis 的持久化机制、主从复制、哨兵、Cluster 集群和运维排查。前置知识：分布式锁（第三篇）。

一、持久化

1.1 为什么需要持久化

Redis 是内存数据库，重启后数据全部丢失。
持久化将内存数据保存到磁盘，重启后可以恢复。

两种持久化方式：
  RDB（Redis Database）   — 定时快照
  AOF（Append Only File） — 追加写日志

1.2 RDB 快照

原理：在某个时间点，把内存中的所有数据生成一份快照文件（dump.rdb）

触发方式：
  1. 自动触发（配置规则）
  2. 手动触发（SAVE / BGSAVE）
  3. 关闭时触发（shutdown）

自动触发配置：
  save 900 1        — 900秒内有1次修改就触发
  save 300 10       — 300秒内有10次修改
  save 60 10000     — 60秒内有10000次修改

BGSAVE 工作方式：
  1. 主进程 fork 子进程
  2. 子进程将内存数据写入临时 RDB 文件
  3. 写完后替换旧的 RDB 文件
  4. 主进程继续处理请求（不影响服务）

优点：
  - 文件紧凑，恢复速度快
  - fork 子进程不影响主进程
  - 适合备份和容灾

缺点：
  - 不是实时的，两次快照之间的数据可能丢失
  - fork 子进程时如果数据量大，可能短暂影响性能

1.3 AOF 日志

原理：将每个写命令追加到 AOF 文件（appendonly.aof）

工作流程：
  1. 客户端发送写命令
  2. Redis 执行命令
  3. 将命令追加到 AOF 缓冲区
  4. 根据策略将缓冲区写入文件

刷盘策略（appendfsync）：
  always     — 每个写命令都刷盘（最安全，最慢）
  everysec   — 每秒刷盘一次（推荐，最多丢1秒数据）
  no         — 由操作系统决定（最快，可能丢较多数据）

优点：
  - 数据更安全（最多丢1秒）
  - AOF 文件可读（可以手动修改恢复数据）

缺点：
  - 文件比 RDB 大
  - 恢复速度比 RDB 慢

1.4 AOF 重写

问题：AOF 文件越来越大（SET a 1, SET a 2, SET a 3 → 只需要 SET a 3）

AOF 重写：压缩 AOF 文件，只保留最终状态的数据

触发方式：
  auto-aof-rewrite-min-size 64mb      — AOF 文件超过 64MB 触发
  auto-aof-rewrite-percentage 100     — 文件大小比上次重写后增长 100%

手动触发：
  BGREWRITEAOF

1.5 RDB + AOF 混合持久化（Redis 4.0+）

配置：aof-use-rdb-preamble yes（默认开启）

工作方式：
  - AOF 重写时，前半部分用 RDB 格式写入（快速加载）
  - 后半部分用 AOF 格式写入增量命令
  - 结合了两者的优点

推荐配置：
  开启 AOF（appendonly yes）
  开启混合持久化（aof-use-rdoc-preamble yes）
  刷盘策略 everysec

1.6 持久化选择

纯缓存（丢了无所谓）：
  关闭持久化，性能最好
  save ""
  appendonly no

缓存 + 允许少量丢失：
  只用 RDB
  适合：Session、验证码

数据不能丢：
  AOF + everysec
  适合：业务数据、计数器

生产环境推荐：
  RDB + AOF 混合持久化
  RDB 用于快速恢复和备份
  AOF 保证数据安全

二、主从复制

2.1 作用

1
2
3

1. 数据备份   — 从节点是主节点的完整副本
2. 读写分离   — 写请求到主节点，读请求到从节点
3. 高可用基础  — 主节点故障时从节点可以提升为主

2.2 配置

# 从节点配置（redis.conf 或命令）
REPLICAOF master-ip 6379

# 或运行时设置
REPLICAOF 192.168.1.100 6379

# 查看主从关系
INFO replication

2.3 复制过程

1. 从节点连接主节点
2. 主节点执行 BGSAVE 生成 RDB 快照
3. 主节点将 RDB 发送给从节点
4. 从节点加载 RDB（全量同步）
5. 之后主节点将新的写命令持续发送给从节点（增量同步）

全量同步：初次连接或断开较久时触发
增量同步：正常情况下的持续同步

2.4 注意事项

1. 主从复制是异步的（主节点写入后立即返回，不等从节点确认）
   → 主节点宕机时可能丢失少量数据

2. 从节点默认只读（read-only）
   → 不应该往从节点写数据

3. 一个主节点可以有多个从节点
   → 从节点也可以作为其他从节点的主节点（链式复制）

三、哨兵（Sentinel）

3.1 问题：主节点宕机了怎么办

主从复制中：
  主节点宕机 → 需要人工把从节点提升为主节点
  → 需要通知所有客户端新的主节点地址
  → 整个过程需要人工干预

哨兵：自动完成这个过程

3.2 哨兵功能

1. 监控    — 持续检查主节点和从节点是否正常
2. 通知    — 节点故障时通知管理员或应用
3. 自动故障转移 — 主节点故障时自动将从节点提升为主节点
4. 配置提供者 — 客户端从哨兵获取当前主节点地址

3.3 哨兵部署

至少 3 个哨兵节点（保证选举的多数派）

部署结构：
  Redis Master        — 192.168.1.100:6379
  Redis Slave 1       — 192.168.1.101:6379
  Redis Slave 2       — 192.168.1.102:6379
  Sentinel 1          — 192.168.1.100:26379
  Sentinel 2          — 192.168.1.101:26379
  Sentinel 3          — 192.168.1.102:26379

# sentinel.conf
port 26379
sentinel monitor mymaster 192.168.1.100 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1

monitor          — 监控的主节点名称、IP、端口、法定人数
down-after       — 多久无响应判定为主观下线
failover-timeout  — 故障转移超时
parallel-syncs   — 故障转移后多少个从节点同时同步新主节点

3.4 故障转移流程

1. 哨兵每秒向主节点发送 PING
2. 超过 down-after 时间无响应 → 主观下线
3. 多数哨兵（≥ 2 个）认为主节点下线 → 客观下线
4. 哨兵选举一个从节点提升为新主节点
5. 其他从节点改为复制新主节点
6. 哨兵更新配置，通知客户端新主节点地址
7. 旧主节点恢复后变为新主节点的从节点

3.5 .NET 连接哨兵

// StackExchange.Redis 支持哨兵
var config = new ConfigurationOptions
{
    ServiceName = "mymaster",    // 哨兵监控的 master 名称
    AbortOnConnectFail = false
};
config.EndPoints.Add("192.168.1.100:26379");
config.EndPoints.Add("192.168.1.101:26379");
config.EndPoints.Add("192.168.1.102:26379");

var connection = ConnectionMultiplexer.Connect(config);
// 自动从哨兵获取当前主节点地址
// 主节点切换后自动重连新主节点

四、Cluster 集群

4.1 为什么需要 Cluster

主从 + 哨兵的问题：
  - 主节点只有一个，写入压力集中在主节点
  - 主节点内存有限，单机无法存储更多数据
  - 水平扩展困难

Cluster 解决：
  - 数据分片（Sharding）— 数据分散到多个主节点
  - 水平扩展 — 加节点即可扩容
  - 高可用 — 每个主节点有从节点，自动故障转移

4.2 Cluster 架构

最小集群：6 个节点（3 主 3 从）

  Master-1 (slot 0-5460)    ←→ Slave-1
  Master-2 (slot 5461-10922) ←→ Slave-2
  Master-3 (slot 10923-16383) ←→ Slave-3

  共 16384 个 Hash Slot
  每个主节点负责一部分 Slot
  key 的 slot = CRC16(key) % 16384

4.3 创建 Cluster

# 每个节点的 redis.conf
port 7001
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

# 启动 6 个节点（7001-7006）
redis-server redis.conf

# 创建集群
redis-cli --cluster create \
  127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 \
  127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 \
  --cluster-replicas 1

4.4 Cluster 操作

# 查看集群信息
redis-cli -c -p 7001 cluster info
redis-cli -c -p 7001 cluster nodes

# 查看某个 key 在哪个 slot
redis-cli -c -p 7001 cluster keyslot "user:1"

# 加减节点
redis-cli --cluster add-node new_host:port existing_host:port
redis-cli --cluster reshard host:port

4.5 Cluster 限制

1. 不支持跨 slot 的多 key 操作（MSET、SUNION 等涉及多个 key 的命令）
   → 可以用 Hash Tag 强制同一 slot：{user}:1, {user}:2

2. 不支持 SELECT 切换数据库（只用 db0）

3. 批量操作需要确保 key 在同一个 slot

4. 集群至少 3 主 3 从

五、运维常用操作

5.1 信息查看

# 服务器信息
INFO server

# 内存使用
INFO memory
# 关注：used_memory_human（已用内存）
#       maxmemory（最大内存限制）
#       mem_fragmentation_ratio（内存碎片率，>1.5 需要关注）

# 客户端连接
INFO clients
# 关注：connected_clients（当前连接数）

# 命令统计
INFO stats
# 关注：total_commands_processed（总命令数）
#       instantaneous_ops_per_sec（每秒操作数）

# 持久化状态
INFO persistence
# 关注：rdb_last_save_time（上次 RDB 保存时间）
#       aof_current_size（AOF 当前大小）

# 复制状态
INFO replication

5.2 性能分析

# 慢查询日志
CONFIG SET slowlog-log-slower-than 10000    # 超过 10ms 记录
CONFIG SET slowlog-max-len 128              # 最多记录 128 条
SLOWLOG GET 10                              # 查看最近 10 条慢查询
SLOWLOG LEN                                # 慢查询数量

# 客户端列表
CLIENT LIST                                # 所有连接

# 监控命令（调试用，不要在生产长时间开）
MONITOR                                    # 实时显示所有命令

5.3 内存优化

# 查看内存使用
MEMORY USAGE key                    # 单个 key 的内存占用
MEMORY DOCTOR                       # 内存诊断建议

# 大 key 排查
redis-cli --bigkeys                 # 扫描大 key
redis-cli --memkeys                 # 按内存排序的 key

# 清理过期 key
SCAN 0 MATCH session:* COUNT 1000  # 安全扫描

5.4 常用运维命令

# 查看配置
CONFIG GET maxmemory
CONFIG GET maxmemory-policy

# 在线修改配置
CONFIG SET maxmemory 2gb
CONFIG SET maxmemory-policy allkeys-lru

# 查看连接数
CLIENT LIST | wc -l

# 断开客户端
CLIENT KILL ADDR:PORT

# 数据库大小
DBSIZE

# 清空当前数据库
FLUSHDB ASYNC                      # 异步清空（不阻塞）

# 查看所有数据库的 key 数量
INFO keyspace

六、常见问题排查

6.1 内存满了

现象：OOM，写入返回错误

排查：
  1. INFO memory → 看 used_memory 和 maxmemory
  2. redis-cli --bigkeys → 找大 key
  3. 检查是否有过期策略

解决：
  - 设置 maxmemory-policy（推荐 allkeys-lru）
  - 清理无用 key
  - 扩容（增加内存或用 Cluster）
  - 检查是否有大 value（拆分为多个小 key）

6.2 响应变慢

排查：
  1. SLOWLOG GET 10 → 慢查询
  2. INFO memory → 看碎片率（mem_fragmentation_ratio）
  3. INFO clients → 连接数是否过多
  4. INFO persistence → 是否在频繁 BGSAVE

常见原因：
  - 大 key 操作（DEL 一个很大的 key 会阻塞）
  - 持久化阻塞（fork 耗时）
  - 内存碎片太多（重启可以解决）
  - 连接数过多
  - 使用了 KEYS * 等危险命令

6.3 主从延迟

排查：
  INFO replication
  → master_repl_offset 和 slave_repl_offset 差距大

原因：
  - 网络延迟
  - 从节点性能不足
  - 主节点写入量太大
  - 大 key 同步耗时

解决：
  - 检查网络
  - 提升从节点配置
  - 避免写入大 value

七、系列总结

7.1 知识体系回顾

第一篇：基础与数据类型
  - 核心概念、5种数据类型、通用命令、.NET 客户端

第二篇：缓存实战
  - 缓存模式、过期策略、淘汰策略、穿透/击穿/雪崩

第三篇：分布式锁
  - 锁原理、Lua 解锁、看门狗、可重入、RedLock、.NET 封装

第四篇：持久化与高可用
  - RDB、AOF、主从复制、哨兵、Cluster、运维排查

7.2 核心要点

1. Redis 单线程 + IO 多路复用 = 高性能
2. 5 种数据类型各有适用场景，选对了事半功倍
3. 缓存用 Cache Aside 模式，更新时删缓存不是更新缓存
4. 缓存三大问题必须能答：穿透（布隆过滤器）、击穿（互斥锁）、雪崩（随机过期）
5. 分布式锁三要素：SET NX EX、唯一值、Lua 解锁
6. 生产环境开启 AOF + everysec，推荐混合持久化
7. 高可用至少 3 节点：主从 + 哨兵，或 Cluster
8. 避免 KEYS *、大 value、热点 key 过期时间相同

Redis 学习笔记（三）：分布式锁

Tue, 02 Jun 2026 10:00:00 +0800

写在前面

本文是 Redis 学习笔记系列的第三篇，深入分布式锁的实现原理、常见问题和 .NET 实战封装。前置知识：缓存实战（第二篇）。

一、为什么需要分布式锁

1.1 单机锁的问题

单机环境：
  lock (obj) { ... }     — Monitor
  SemaphoreSlim          — 信号量
  Mutex                  — 互斥体

这些锁只在当前进程内有效。
部署多个实例后，各进程的锁互不影响，无法保证互斥。

1.2 分布式场景

场景：多个订单服务实例，防止同一笔订单被重复处理。

实例 A：处理订单 12345
实例 B：也收到订单 12345 的请求

如果用单机锁，A 和 B 各自加锁成功 → 重复处理

需要一把跨进程、跨机器的锁 → 分布式锁

1.3 分布式锁的要求

1. 互斥性    — 任意时刻只有一个客户端持有锁
2. 可重入    — 同一线程/进程可以重复获取同一把锁
3. 不会死锁  — 持有锁的客户端宕机后锁能自动释放
4. 高性能    — 加锁/解锁要快
5. 高可用    — 锁服务不能成为单点故障

二、Redis 实现分布式锁

2.1 基本原理

加锁：SET lock_key unique_value NX EX 30
  NX  — key 不存在才设置（保证互斥）
  EX  — 过期时间（防止死锁）
  unique_value — 客户端唯一标识（防止误删别人的锁）

解锁：Lua 脚本（原子操作）
  先判断 value 是否匹配 → 匹配才删除

2.2 为什么解锁要用 Lua 脚本

不用 Lua 脚本的问题：

1. 客户端 A 执行 GET lock_key → 返回 "A"
2. 客户端 A 判断 value == "A" → 是我的锁
3. 【此时锁恰好过期，Redis 自动删除】
4. 客户端 B 执行 SET lock_key "B" NX → 成功
5. 客户端 A 执行 DEL lock_key → 删了 B 的锁！

Lua 脚本保证"判断 + 删除"是原子操作：

if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
else
    return 0
end

2.3 基础实现

# 加锁
SET lock:order:12345 "client-uuid-abc" NX EX 30

# 解锁（Lua 脚本）
EVAL "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" 1 lock:order:12345 "client-uuid-abc"

三、锁续期

3.1 问题：业务没处理完锁就过期了

设置锁过期时间 30 秒，但业务处理需要 40 秒：

1. 客户端 A 加锁（30 秒）
2. A 开始处理业务（预计 40 秒）
3. 30 秒后锁自动过期
4. 客户端 B 加锁成功
5. A 处理完业务，释放了 B 的锁 → 严重问题！

3.2 解决：看门狗机制

看门狗（Watchdog）：后台线程定期延长锁的过期时间。

工作方式：
  - 加锁成功后，启动看门狗线程
  - 每隔 lock_time / 3 检查一次
  - 如果锁还持有（value 匹配），重置过期时间
  - 如果业务处理完成，看门狗停止续期

示例：
  锁过期时间 30 秒
  看门狗每 10 秒续期一次
  业务处理 40 秒：
    0s    加锁（30s 过期）
    10s   续期（30s 过期）
    20s   续期（30s 过期）
    30s   续期（30s 过期）
    40s   业务完成，主动释放锁，看门狗停止

四、可重入锁

4.1 问题：同一线程多次加锁

1
2
3

方法 A 加锁 → 调用方法 B → 方法 B 也加同一把锁

如果锁不可重入，方法 B 等待方法 A 释放 → 死锁

4.2 实现：Hash + 计数器

# 加锁（可重入）
# key = lock name, field = client_id, value = 重入次数
HSET lock:order:12345 "client-uuid-abc" 1
# 重入时计数 +1
HINCRBY lock:order:12345 "client-uuid-abc" 1

# 解锁时计数 -1
HINCRBY lock:order:12345 "client-uuid-abc" -1
# 计数归零时删除 key

五、.NET 实战封装

5.1 基础分布式锁

public interface IDistributedLock : IDisposable
{
    Task<bool> TryAcquireAsync(TimeSpan timeout);
    Task ReleaseAsync();
}

public class RedisDistributedLock : IDistributedLock
{
    private readonly IDatabase _db;
    private readonly string _lockKey;
    private readonly string _lockValue;
    private readonly TimeSpan _expiry;
    private bool _disposed;

    // Lua 解锁脚本（只删自己的锁）
    private static readonly LuaScript UnlockScript = LuaScript.Prepare(
        @"if redis.call('get', @key) == @value then
            return redis.call('del', @key)
          else
            return 0
          end");

    public RedisDistributedLock(
        IDatabase db, string lockKey, TimeSpan expiry)
    {
        _db = db;
        _lockKey = lockKey;
        _lockValue = Guid.NewGuid().ToString();  // 唯一标识
        _expiry = expiry;
    }

    public async Task<bool> TryAcquireAsync(TimeSpan timeout)
    {
        var deadline = DateTime.UtcNow + timeout;
        var retryDelay = TimeSpan.FromMilliseconds(50);

        while (DateTime.UtcNow < deadline)
        {
            var acquired = await _db.StringSetAsync(
                _lockKey, _lockValue, _expiry, When.NotExists);

            if (acquired)
                return true;

            await Task.Delay(retryDelay);
        }

        return false;  // 超时未获取到锁
    }

    public async Task ReleaseAsync()
    {
        await _db.ScriptEvaluateAsync(UnlockScript,
            new { key = (RedisKey)_lockKey, value = _lockValue });
    }

    public void Dispose()
    {
        if (!_disposed)
        {
            ReleaseAsync().GetAwaiter().GetResult();
            _disposed = true;
        }
    }
}

5.2 使用方式

public class OrderService
{
    private readonly IConnectionMultiplexer _redis;

    public OrderService(IConnectionMultiplexer redis) => _redis = redis;

    public async Task ProcessOrderAsync(string orderId)
    {
        var db = _redis.GetDatabase();
        var lockKey = $"lock:order:{orderId}";

        await using var @lock = new RedisDistributedLock(
            db, lockKey, TimeSpan.FromSeconds(30));

        // 尝试获取锁，最多等 5 秒
        var acquired = await @lock.TryAcquireAsync(TimeSpan.FromSeconds(5));

        if (!acquired)
        {
            throw new InvalidOperationException($"获取订单 {orderId} 的锁失败");
        }

        // 获取锁成功，处理业务
        await DoProcessOrder(orderId);

        // 离开 using 块时自动释放锁
    }
}

5.3 带看门狗的分布式锁

public class RedisDistributedLockWithWatchdog : IDistributedLock
{
    private readonly IDatabase _db;
    private readonly string _lockKey;
    private readonly string _lockValue;
    private readonly TimeSpan _expiry;
    private readonly TimeSpan _renewInterval;
    private CancellationTokenSource? _cts;
    private bool _disposed;

    private static readonly LuaScript UnlockScript = LuaScript.Prepare(
        @"if redis.call('get', @key) == @value then
            return redis.call('del', @key)
          else
            return 0
          end");

    private static readonly LuaScript RenewScript = LuaScript.Prepare(
        @"if redis.call('get', @key) == @value then
            return redis.call('expire', @key, @ttl)
          else
            return 0
          end");

    public RedisDistributedLockWithWatchdog(
        IDatabase db, string lockKey, TimeSpan expiry)
    {
        _db = db;
        _lockKey = lockKey;
        _lockValue = Guid.NewGuid().ToString();
        _expiry = expiry;
        _renewInterval = TimeSpan.FromTicks(expiry.Ticks / 3);
    }

    public async Task<bool> TryAcquireAsync(TimeSpan timeout)
    {
        var deadline = DateTime.UtcNow + timeout;
        var retryDelay = TimeSpan.FromMilliseconds(50);

        while (DateTime.UtcNow < deadline)
        {
            var acquired = await _db.StringSetAsync(
                _lockKey, _lockValue, _expiry, When.NotExists);

            if (acquired)
            {
                StartWatchdog();
                return true;
            }

            await Task.Delay(retryDelay);
        }

        return false;
    }

    private void StartWatchdog()
    {
        _cts = new CancellationTokenSource();
        _ = Task.Run(async () =>
        {
            while (!_cts.Token.IsCancellationRequested)
            {
                await Task.Delay(_renewInterval, _cts.Token);

                try
                {
                    await _db.ScriptEvaluateAsync(RenewScript,
                        new
                        {
                            key = (RedisKey)_lockKey,
                            value = _lockValue,
                            ttl = (int)_expiry.TotalSeconds
                        });
                }
                catch (OperationCanceledException) { break; }
            }
        }, _cts.Token);
    }

    public async Task ReleaseAsync()
    {
        _cts?.Cancel();

        await _db.ScriptEvaluateAsync(UnlockScript,
            new { key = (RedisKey)_lockKey, value = _lockValue });
    }

    public void Dispose()
    {
        if (!_disposed)
        {
            ReleaseAsync().GetAwaiter().GetResult();
            _cts?.Dispose();
            _disposed = true;
        }
    }
}

六、RedLock 算法

6.1 单节点锁的问题

Redis 主从复制场景：
  1. 客户端 A 在 Master 加锁成功
  2. Master 还没同步到 Slave 就宕机了
  3. Slave 被提升为 Master（锁数据丢失）
  4. 客户端 B 加锁成功 → 两把锁同时存在！

RedLock：在多个独立的 Redis 实例上加锁，多数成功才算成功。

6.2 RedLock 流程

假设 5 个独立的 Redis 节点：

1. 记录开始时间
2. 依次向 5 个节点加锁（SET NX EX，很快）
3. 计算加锁耗时
4. 如果在 N/2+1（即 3）个节点加锁成功，且耗时 < 锁有效期 → 加锁成功
5. 失败则向所有节点释放锁

6.3 .NET 使用 RedLock.net

1
2

dotnet add package RedLock.net
dotnet add package RedLock.net.SERedis

// 注册 RedLockFactory
builder.Services.AddSingleton<RedLockFactory>(sp =>
{
    var connection = sp.GetRequiredService<IConnectionMultiplexer>();
    return RedLockFactory.Create(connection);
});

// 使用
public class OrderService
{
    private readonly RedLockFactory _lockFactory;

    public OrderService(RedLockFactory lockFactory) => _lockFactory = lockFactory;

    public async Task ProcessOrderAsync(string orderId)
    {
        var resource = $"lock:order:{orderId}";
        var expiry = TimeSpan.FromSeconds(30);
        var wait = TimeSpan.FromSeconds(5);
        var retry = TimeSpan.FromMilliseconds(200);

        await using var redLock = await _lockFactory.CreateLockAsync(
            resource, expiry, wait, retry);

        if (redLock.IsAcquired)
        {
            await DoProcessOrder(orderId);
        }
        else
        {
            throw new InvalidOperationException("获取锁失败");
        }
    }
}

七、分布式锁注意事项

7.1 锁过期时间设置

太短：业务没处理完锁就过期了 → 失去互斥保护
太长：客户端宕机后锁很久才释放 → 其他客户端等待太久

建议：
  - 根据业务最大执行时间设置（通常是秒级）
  - 加上看门狗续期机制
  - 一般设置 10-30 秒

7.2 锁粒度

粒度太粗：锁整个业务 → 并发度低
粒度太细：锁太多 key → 管理复杂、性能开销大

建议：锁到具体业务实体
  lock:order:12345          — 锁一个订单
  lock:inventory:SKU001     — 锁一个 SKU 的库存
  lock:user:phone:13800138000 — 锁一个手机号的发送频率

7.3 锁的释放

一定要在 finally 中释放锁：

try
{
    var acquired = await @lock.TryAcquireAsync(timeout);
    if (acquired)
    {
        await DoWork();
    }
}
finally
{
    await @lock.ReleaseAsync();  // 无论如何都释放
}

或者用 using/await using 自动释放

八、小结

本文学习了分布式锁：

为什么需要分布式锁
Redis 分布式锁原理（SET NX EX + Lua 解锁）
锁续期（看门狗机制）
可重入锁
.NET 实战封装（基础锁、带看门狗的锁）
RedLock 算法和 RedLock.net
锁的注意事项（过期时间、粒度、释放）

下一篇将学习持久化、高可用和运维。

Redis 学习笔记（二）：缓存实战

Mon, 01 Jun 2026 10:00:00 +0800

写在前面

本文是 Redis 学习笔记系列的第二篇，介绍缓存的使用模式、过期和淘汰策略，以及缓存穿透、击穿、雪崩三大问题的解决方案。前置知识：基础与数据类型（第一篇）。

一、缓存模式

1.1 Cache Aside（旁路缓存）

最常用的缓存模式，应用代码同时管理缓存和数据库。

读取：
  1. 先查缓存
  2. 缓存命中 → 直接返回
  3. 缓存未命中 → 查数据库 → 写入缓存 → 返回

更新：
  1. 先更新数据库
  2. 再删除缓存（不是更新缓存）

为什么是删除而不是更新缓存？
  - 更新缓存在并发场景下可能导致数据不一致
  - 删除更简单，下次读取时自然会重建

public class ProductService
{
    private readonly IDatabase _redis;
    private readonly IProductRepository _repo;

    public ProductService(IConnectionMultiplexer redis, IProductRepository repo)
    {
        _redis = redis.GetDatabase();
        _repo = repo;
    }

    // 读取：先缓存后数据库
    public async Task<Product?> GetProductAsync(int id)
    {
        var cacheKey = $"cache:product:{id}";

        // 1. 查缓存
        var cached = await _redis.StringGetAsync(cacheKey);
        if (cached.HasValue)
        {
            return JsonSerializer.Deserialize<Product>(cached!);
        }

        // 2. 查数据库
        var product = await _repo.GetByIdAsync(id);
        if (product == null) return null;

        // 3. 写入缓存（过期时间 30 分钟）
        var json = JsonSerializer.Serialize(product);
        await _redis.StringSetAsync(cacheKey, json, TimeSpan.FromMinutes(30));

        return product;
    }

    // 更新：先数据库后删缓存
    public async Task UpdateProductAsync(Product product)
    {
        // 1. 更新数据库
        await _repo.UpdateAsync(product);

        // 2. 删除缓存
        await _redis.KeyDeleteAsync($"cache:product:{product.Id}");
    }
}

1.2 Read/Write Through

缓存代理层负责读写数据库，应用只和缓存交互。

读取：
  应用 → 缓存 → （未命中）缓存层自动查数据库并回填

写入：
  应用 → 缓存 → 缓存层同步更新数据库

特点：应用代码更简单，但需要缓存中间件支持

1.3 Write Behind（异步写回）

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

优点：写入性能极高
缺点：数据可能丢失（宕机时未落盘的数据丢失）
适用：写密集、允许少量丢失的场景

二、过期策略

2.1 设置过期时间

# 设置时指定过期
SET cache:key "data" EX 1800          # 秒
SETEX cache:key 1800 "data"           # 等价

# 对已存在的 key 设置过期
EXPIRE cache:key 1800                 # 秒
PEXPIRE cache:key 1800000             # 毫秒

# 指定过期时间点
EXPIREAT cache:key 1740000000         # Unix 时间戳

# 移除过期时间
PERSIST cache:key

1
2
3

// StackExchange.Redis
await db.StringSetAsync("cache:key", "data", TimeSpan.FromMinutes(30));
await db.KeyExpireAsync("cache:key", TimeSpan.FromMinutes(30));

2.2 过期删除机制

Redis 采用两种策略结合：

1. 惰性删除（Lazy Expiration）
   - 访问 key 时检查是否过期
   - 过期了才删除
   - 优点：CPU 友好
   - 缺点：过期了但没人访问的 key 会占用内存

2. 定期删除（Periodic Expiration）
   - 每秒执行 10 次（默认）
   - 随机检查一批设置了过期的 key
   - 删除已过期的
   - 如果过期比例超过 25%，继续检查
   - 控制在 25ms 以内（避免阻塞）

两者结合：
  定期删除保证内存不会被大量过期 key 占满
  惰性删除保证访问时一定能拿到正确结果

三、淘汰策略

当内存使用达到 maxmemory 限制时，Redis 如何选择删除哪些 key。

3.1 配置

1
2
3

# redis.conf 或运行时设置
CONFIG SET maxmemory 1gb
CONFIG SET maxmemory-policy allkeys-lru

3.2 8 种淘汰策略

不淘汰（默认）：
  noeviction         — 内存满了直接报错，不删除任何 key

只淘汰设置了过期的 key：
  volatile-lru       — 淘汰设置了过期的、最久未使用的 key
  volatile-lfu       — 淘汰设置了过期的、使用频率最低的 key（Redis 4.0+）
  volatile-ttl       — 淘汰设置了过期的、TTL 最短的 key
  volatile-random    — 随机淘汰设置了过期的 key

淘汰所有 key：
  allkeys-lru        — 淘汰最久未使用的 key（缓存场景最常用）
  allkeys-lfu        — 淘汰使用频率最低的 key（Redis 4.0+）
  allkeys-random     — 随机淘汰

3.3 策略选择

缓存场景（Redis 主要做缓存）：
  allkeys-lru        — 推荐，淘汰最不常用的数据
  allkeys-lfu        — 更精确，但要更多内存记录频率

缓存 + 持久化场景：
  volatile-lru       — 只淘汰有过期时间的，持久化的数据不受影响

不确定：
  allkeys-lru        — 最稳妥的选择

四、缓存穿透

4.1 问题描述

查询一个数据库中不存在的数据，缓存中也没有。

流程：
  查缓存 → 没有 → 查数据库 → 也没有 → 返回 null → 不写缓存

问题：每次请求都会打到数据库。
如果有恶意攻击，大量请求查询不存在的数据，数据库可能被打挂。

4.2 解决方案

方案一：缓存空值

public async Task<Product?> GetProductAsync(int id)
{
    var cacheKey = $"cache:product:{id}";
    var cached = await _redis.StringGetAsync(cacheKey);

    if (cached.HasValue)
    {
        if (cached == "NULL") return null;  // 命中空值缓存
        return JsonSerializer.Deserialize<Product>(cached!);
    }

    var product = await _repo.GetByIdAsync(id);

    if (product == null)
    {
        // 缓存空值，短过期时间（防止占用太多内存）
        await _redis.StringSetAsync(cacheKey, "NULL", TimeSpan.FromMinutes(5));
        return null;
    }

    await _redis.StringSetAsync(cacheKey, JsonSerializer.Serialize(product),
        TimeSpan.FromMinutes(30));
    return product;
}

优点：简单直接
缺点：
  - 占用额外内存
  - 过期时间短，频繁查数据库
  - 攻击者换不同的 key 就失效了

方案二：布隆过滤器

在缓存前面加一层布隆过滤器：
  - 所有可能存在的数据哈希到布隆过滤器中
  - 请求先过布隆过滤器
  - 布隆过滤器说不存在 → 一定不存在，直接返回
  - 布隆过滤器说存在 → 可能有，再去查缓存和数据库

优点：内存占用极小
缺点：
  - 需要预先加载数据
  - 有误判率（说存在但实际不存在）
  - 删除困难

方案三：参数校验

最简单的方式：在入口处校验请求参数。
  - ID 不合法直接返回
  - 不存在的枚举值直接返回
  - 不合理的范围直接返回

这是第一道防线，必须做。

五、缓存击穿

5.1 问题描述

一个热点 key 过期的瞬间，大量并发请求同时到达。

流程：
  key 存在时 → 所有请求命中缓存 → 正常
  key 过期瞬间 → 大量请求同时查数据库 → 数据库压力暴增

典型场景：热点新闻、秒杀商品

5.2 解决方案

方案一：互斥锁

public async Task<Product?> GetProductWithLockAsync(int id)
{
    var cacheKey = $"cache:product:{id}";
    var lockKey = $"lock:cache:product:{id}";

    // 1. 查缓存
    var cached = await _redis.StringGetAsync(cacheKey);
    if (cached.HasValue)
    {
        if (cached == "NULL") return null;
        return JsonSerializer.Deserialize<Product>(cached!);
    }

    // 2. 获取分布式锁（只有一个请求能查数据库）
    var lockAcquired = await _redis.StringSetAsync(
        lockKey, "1", TimeSpan.FromSeconds(10),
        When.NotExists);  // NX

    if (lockAcquired)
    {
        try
        {
            // 获得锁，查数据库
            var product = await _repo.GetByIdAsync(id);
            if (product == null)
            {
                await _redis.StringSetAsync(cacheKey, "NULL", TimeSpan.FromMinutes(5));
                return null;
            }

            await _redis.StringSetAsync(cacheKey,
                JsonSerializer.Serialize(product),
                TimeSpan.FromMinutes(30));
            return product;
        }
        finally
        {
            await _redis.KeyDeleteAsync(lockKey);
        }
    }
    else
    {
        // 没获得锁，等一下再重试
        await Task.Delay(100);
        return await GetProductWithLockAsync(id);  // 递归重试
    }
}

方案二：逻辑过期（不设置真正过期时间）

// 缓存对象中包含逻辑过期时间
public class CacheData<T>
{
    public T? Data { get; set; }
    public DateTime ExpireTime { get; set; }
}

public async Task<Product?> GetProductWithLogicalExpireAsync(int id)
{
    var cacheKey = $"cache:product:{id}";
    var cached = await _redis.StringGetAsync(cacheKey);

    if (!cached.HasValue)
    {
        // 缓存中没有，查数据库并缓存（不过期）
        return await LoadToCacheAsync(id);
    }

    var cacheData = JsonSerializer.Deserialize<CacheData<Product>>(cached!);

    // 判断逻辑过期
    if (cacheData!.ExpireTime > DateTime.UtcNow)
    {
        return cacheData.Data;  // 未过期，直接返回
    }

    // 逻辑过期，异步更新缓存（不阻塞当前请求）
    _ = Task.Run(() => LoadToCacheAsync(id));

    // 返回旧数据（用户能接受短暂的旧数据）
    return cacheData.Data;
}

private async Task<Product?> LoadToCacheAsync(int id)
{
    var product = await _repo.GetByIdAsync(id);
    var cacheData = new CacheData<Product>
    {
        Data = product,
        ExpireTime = DateTime.UtcNow.AddMinutes(30)
    };

    await _redis.StringSetAsync(
        $"cache:product:{id}",
        JsonSerializer.Serialize(cacheData));

    return product;
}

互斥锁 vs 逻辑过期：
  互斥锁：保证数据一致，但并发高时部分请求等待
  逻辑过期：不阻塞请求，但可能返回旧数据

选择：
  数据一致性要求高 → 互斥锁
  高性能优先、允许短暂旧数据 → 逻辑过期

方案三：热点 key 永不过期

1
2

对确定的热点 key 不设置过期时间，由后台任务定期更新。
简单但有风险：后台任务挂了数据就不更新了。

六、缓存雪崩

6.1 问题描述

大量缓存 key 在同一时刻过期，或者 Redis 宕机。

场景1：大量 key 设置了相同的过期时间（如 30 分钟）
  → 30 分钟后这些 key 同时过期
  → 请求全部打到数据库

场景2：Redis 节点宕机
  → 所有请求打到数据库

6.2 解决方案

方案一：过期时间加随机值

// 过期时间 = 基础时间 + 随机时间
var baseExpiry = TimeSpan.FromMinutes(30);
var randomExpiry = TimeSpan.FromSeconds(Random.Shared.Next(1, 300));
await _redis.StringSetAsync(cacheKey, json, baseExpiry + randomExpiry);
// 30 分钟 ~ 35 分钟内随机过期，避免同时失效

方案二：多级缓存

L1 缓存（本地内存）→ L2 缓存（Redis）→ 数据库

请求流程：
  本地缓存命中 → 返回
  本地缓存未命中 → Redis 缓存命中 → 写入本地缓存 → 返回
  Redis 也未命中 → 数据库 → 写入 Redis + 本地缓存 → 返回

工具：
  .NET MemoryCache 做本地缓存
  缓存一致性由过期时间控制

public class MultiLevelCacheService
{
    private readonly IMemoryCache _localCache;
    private readonly IDatabase _redis;

    public MultiLevelCacheService(IMemoryCache localCache, IConnectionMultiplexer redis)
    {
        _localCache = localCache;
        _redis = redis.GetDatabase();
    }

    public async Task<T?> GetAsync<T>(string key) where T : class
    {
        // L1: 本地缓存
        if (_localCache.TryGetValue(key, out T? localValue))
        {
            return localValue;
        }

        // L2: Redis
        var redisValue = await _redis.StringGetAsync(key);
        if (redisValue.HasValue)
        {
            var result = JsonSerializer.Deserialize<T>(redisValue!);
            // 回填本地缓存（短过期）
            _localCache.Set(key, result, TimeSpan.FromMinutes(1));
            return result;
        }

        return null;
    }
}

方案三：高可用部署

Redis 宕机导致雪崩的预防：
  - 主从复制 + 哨兵（自动故障转移）
  - Redis Cluster（分片 + 高可用）
  - 限流降级（数据库前加限流，防止被打挂）

七、缓存最佳实践

7.1 过期时间设置

短过期（1-5 分钟）：
  - 验证码
  - Session
  - 短时效的查询结果

中过期（30-60 分钟）：
  - 商品信息
  - 用户资料
  - 配置信息

长过期（1-24 小时）：
  - 不常变化的数据
  - 字典数据
  - 静态内容

永远不过期：
  - 热点数据（由应用主动更新）

7.2 缓存粒度

粒度太粗：缓存整个页面 → 更新频繁，命中率低
粒度太细：缓存每个字段 → 管理复杂，请求次数多

推荐：按业务实体缓存（一个商品、一个用户）

7.3 缓存预热

系统启动时，主动加载热点数据到缓存：
  - 启动时加载排行榜 TOP 100
  - 启动时加载热门商品
  - 启动时加载系统配置

避免：系统刚启动时大量请求直接打到数据库

八、三大问题对比

问题      原因                    解决方案
────────  ──────────────────      ──────────────
穿透      查询不存在的数据         缓存空值、布隆过滤器、参数校验
击穿      热点 key 过期瞬间         互斥锁、逻辑过期、永不过期
雪崩      大量 key 同时过期         过期时间加随机、多级缓存、高可用

九、小结

本文学习了缓存实战：

缓存模式（Cache Aside、Read/Write Through）
过期策略（惰性删除 + 定期删除）
淘汰策略（LRU、LFU、TTL 等 8 种）
缓存穿透及解决方案（缓存空值、布隆过滤器）
缓存击穿及解决方案（互斥锁、逻辑过期）
缓存雪崩及解决方案（随机过期、多级缓存）
缓存最佳实践

下一篇将学习分布式锁：实现原理、锁续期和 .NET 封装。

Redis 学习笔记（一）：基础与数据类型

Sun, 31 May 2026 10:00:00 +0800

写在前面

本文是 Redis 学习笔记系列的第一篇，介绍 Redis 的核心概念、5 种基本数据类型及其应用场景，以及 .NET 客户端的使用。基于 Redis 7.x 版本。

一、Redis 是什么

1.1 定义

Redis（Remote Dictionary Server）是一个基于内存的键值存储系统，可以用作数据库、缓存和消息中间件。

核心特征：
1. 基于内存    — 读写极快（10万+ QPS）
2. 单线程      — 无并发竞争问题（Redis 6.0+ 网络 I/O 多线程）
3. 持久化      — 支持RDB和AOF两种方式，数据不丢
4. 丰富数据类型 — String、Hash、List、Set、Sorted Set 等
5. 高可用      — 主从复制、哨兵、集群

1.2 为什么 Redis 这么快

1. 基于内存
   内存读取速度是纳秒级，磁盘是毫秒级
   差距 10万 倍

2. 单线程 + IO 多路复用
   单线程避免了锁竞争和上下文切换
   epoll/kqueue 实现高效网络 IO
   命令排队串行执行，没有并发问题

3. 高效的数据结构
   底层用 C 实现了 SDS、跳表、压缩列表等高效结构

4. Redis 6.0+ 的多线程
   网络读写用多线程（IO 多路复用仍然是单线程）
   命令执行仍然是单线程
   只提升网络 IO 性能，不改变数据一致性模型

1.3 典型应用场景

缓存              — 最常见的用法，热点数据缓存
分布式锁           — setnx 实现互斥
计数器             — 文章阅读数、点赞数
排行榜             — Sorted Set 实现
会话存储           — 用户登录状态（Session）
限流               — 滑动窗口限流
地理位置           — 附近的人、店铺
发布订阅           — 消息通知

二、安装

2.1 Docker 安装

docker run -d \
  --name redis \
  -p 6379:6379 \
  -v redis-data:/data \
  redis:7.4 redis-server --appendonly yes

--appendonly yes    — 开启 AOF 持久化

连接：
  redis-cli -h localhost -p 6379

2.2 Windows 安装

# 方式一：winget
winget install Redis.Redis

# 方式二：下载安装包
# https://github.com/tporadowski/redis/releases

2.3 验证

redis-cli ping
# 返回 PONG 表示连接成功

# 查看版本
redis-server --version

三、数据类型详解

3.1 String（字符串）

最基础的类型，可以存储字符串、数字、JSON、二进制数据（最大 512MB）。

# 基本操作
SET name "张三"
GET name                          # "张三"

# SET 选项
SET lock "1" EX 30 NX             # EX 过期时间（秒），NX 不存在才设置（分布式锁）
SET user:1 '{"name":"张三","age":25}'  # 存储 JSON

# 批量操作
MSET key1 "v1" key2 "v2" key3 "v3"
MGET key1 key2 key3

# 数值操作
SET counter 100
INCR counter                      # 101（原子自增）
INCRBY counter 10                 # 111
DECR counter                      # 110
INCRBYFLOAT price 0.5             # 浮点数增减

# 过期时间
SET session:token "user_data" EX 1800    # 30 分钟后过期
EXPIRE name 60                           # 设置已存在的 key 过期时间
TTL name                                 # 查看剩余过期时间（-1 永不过期，-2 已过期）

# 其他
STRLEN name                       # 字符串长度
APPEND name "先生"                 # 追加
SETEX cache:key 300 "data"        # 设置值 + 过期时间（原子操作）

应用场景：
  - 缓存（存 JSON）
  - 计数器（INCR 原子操作）
  - 分布式锁（SET NX EX）
  - Session 存储
  - 限流（INCR + EXPIRE）

3.2 Hash（哈希）

键值对集合，类似 C# 的 Dictionary<string, string>。适合存储对象。

# 基本操作
HSET user:1 name "张三" age 25 email "zhang@test.com"
HGET user:1 name                  # "张三"
HGET user:1 age                   # "25"

# 批量操作
HMSET user:2 name "李四" age 30 role "admin"

# 获取所有字段
HGETALL user:1
# name: "张三", age: "25", email: "zhang@test.com"

# 获取指定字段
HMGET user:1 name age

# 字段操作
HDEL user:1 email                 # 删除字段
HEXISTS user:1 name               # 字段是否存在（1/0）
HLEN user:1                       # 字段数量

# 数值操作
HINCRBY user:1 age 1              # age + 1

# 批量设置字段值（Redis 7.4+）
HSET user:3 name "王五" age 28 role "user"

应用场景：
  - 存储对象（用户信息、商品信息）
  - 比用 String 存 JSON 更灵活（可以只读/写某个字段）
  - 购物车（用户ID为key，商品ID为field，数量为value）

String 存对象 vs Hash 存对象：
  String: SET user:1 '{"name":"张三","age":25}'
          → 修改 age 要读出来改完再写回去

  Hash:   HSET user:1 name "张三" age 25
          → HINCRBY user:1 age 1（直接修改某个字段）

3.3 List（列表）

有序的字符串列表，按插入顺序排序，支持从两端操作。

# 从左/右推入
LPUSH tasks "task3"
LPUSH tasks "task2"
LPUSH tasks "task1"               # list: [task1, task2, task3]
RPUSH tasks "task4"               # list: [task1, task2, task3, task4]

# 从左/右弹出
LPOP tasks                        # "task1"
RPOP tasks                        # "task4"

# 阻塞弹出（阻塞直到有数据或超时）
BLPOP queue:email 30              # 30 秒内等数据

# 查询
LRANGE tasks 0 -1                 # 查看所有元素
LRANGE tasks 0 2                  # 前3个元素
LLEN tasks                        # 列表长度

# 按索引操作
LINDEX tasks 0                    # 第一个元素
LSET tasks 0 "updated"            # 修改指定位置

# 裁剪（保留指定范围）
LTRIM tasks 0 99                  # 只保留前100个

应用场景：
  - 消息队列（LPUSH + BRPOP）
  - 最新列表（最新文章、最新动态，LTRIM 保留最新N条）
  - 栈（LPUSH + LPOP）
  - 队列（LPUSH + RPOP）

3.4 Set（集合）

无序、不重复的字符串集合。

# 基本操作
SADD tags "Java" "Python" "Go"
SADD tags "Rust"

# 查询
SMEMBERS tags                     # 所有成员
SCARD tags                        # 成员数量
SISMEMBER tags "Java"             # 是否存在（1/0）

# 删除
SREM tags "Rust"
SPOP tags                         # 随机弹出一个

# 集合运算
SADD set-a "a" "b" "c" "d"
SADD set-b "c" "d" "e" "f"

SINTER set-a set-b                # 交集：c, d
SUNION set-a set-b                # 并集：a, b, c, d, e, f
SDIFF set-a set-b                 # 差集（a有b没有）：a, b

# 随机获取
SRANDMEMBER tags 2                # 随机取2个（不删除）

应用场景：
  - 标签系统（文章标签、用户标签）
  - 去重（点赞用户列表、签到用户）
  - 交集运算（共同好友、共同关注）
  - 抽奖（SRANDMEMBER / SPOP 随机抽取）

3.5 Sorted Set（有序集合）

每个成员关联一个分数（score），按分数排序。Redis 中最实用的数据结构之一。

# 添加（score + member）
ZADD leaderboard 100 "张三" 95 "李四" 88 "王五" 92 "赵六"

# 按分数排名（升序，0开始）
ZRANGE leaderboard 0 -1 WITHSCORES
# 王五:88, 赵六:92, 李四:95, 张三:100

# 降序排名
ZREVRANGE leaderboard 0 -1 WITHSCORES
# 张三:100, 李四:95, 赵六:92, 王五:88

# 取 TOP N
ZREVRANGE leaderboard 0 2 WITHSCORES    # 前三名

# 查询成员信息
ZSCORE leaderboard "张三"                # 100（查分数）
ZRANK leaderboard "张三"                 # 排名（升序，从0开始）
ZREVRANK leaderboard "张三"              # 排名（降序，从0开始）

# 增减分数
ZINCRBY leaderboard 5 "李四"            # 李四分数 +5

# 按分数范围查询
ZRANGEBYSCORE leaderboard 90 100 WITHSCORES    # 90-100 分的

# 按排名范围删除
ZREMRANGEBYRANK leaderboard 0 2         # 删除排名最低的3个

# 数量
ZCARD leaderboard                        # 总成员数
ZCOUNT leaderboard 90 100                # 分数在 90-100 之间的数量

应用场景：
  - 排行榜（积分榜、销量榜、热度榜）
  - 延迟队列（score = 执行时间戳）
  - 滑动窗口限流（score = 时间戳）
  - 带权重的数据（按分数排序取 TOP N）

四、其他数据类型

4.1 Bitmap（位图）

SETBIT sign:202605 0 1            # 第1天签到
SETBIT sign:202605 4 1            # 第5天签到
GETBIT sign:202605 0              # 第1天是否签到
BITCOUNT sign:202605              # 本月签到次数

`1`	`应用场景：签到打卡、在线状态、布隆过滤器`

4.2 HyperLogLog（基数统计）

1
2
3

PFADD uv:20260501 "user1" "user2" "user3"
PFADD uv:20260501 "user2" "user4"
PFCOUNT uv:20260501               # 近似去重数量：4

1
2

应用场景：UV 统计、去重计数（占用极小，12KB 可统计 2^64 个不同元素）
注意：结果有 0.81% 的误差

4.3 Stream（流）

# 添加消息
XADD orders * user_id 1 product "手机" amount 3999
# 返回消息 ID：1740000000000-0

# 读取消息
XREAD COUNT 10 BLOCK 5000 STREAMS orders $
# 从最新位置读取，阻塞等待5秒

# 消费者组
XGROUP CREATE orders order-group $ MKSTREAM
XREADGROUP GROUP order-group consumer1 COUNT 1 STREAMS orders >

`1`	`应用场景：消息队列（比 List 更强大，支持消费组、ACK、持久化）`

五、通用命令

# 键操作
KEYS *                            # 查看所有 key（生产环境禁用，用 SCAN）
SCAN 0 MATCH user:* COUNT 100    # 安全遍历
EXISTS key1                       # key 是否存在
DEL key1 key2                     # 删除 key
UNLINK key1                       # 异步删除（大 key 用这个）
TYPE key1                         # 查看 key 类型
RENAME key1 key2                  # 重命名

# 过期时间
EXPIRE key1 60                    # 60秒后过期
PEXPIRE key1 60000                # 毫秒
TTL key1                          # 剩余秒数
PERSIST key1                      # 移除过期时间

# 数据库
SELECT 0                          # 切换数据库（0-15，默认0）
DBSIZE                            # 当前数据库 key 数量
FLUSHDB                           # 清空当前数据库
FLUSHALL                          # 清空所有数据库

# 信息查看
INFO memory                       # 内存使用情况
INFO keyspace                     # 各数据库 key 统计

六、.NET 客户端

6.1 安装

`1`	`dotnet add package StackExchange.Redis`

6.2 基本连接

// 连接 Redis
var connection = ConnectionMultiplexer.Connect("localhost:6379");

// 获取数据库（默认 db0）
var db = connection.GetDatabase();

// 也可以用连接字符串
var connection = ConnectionMultiplexer.Connect(
    "localhost:6379,abortConnect=false,connectTimeout=5000,syncTimeout=5000");

6.3 注册为服务

// Program.cs
builder.Services.AddSingleton<IConnectionMultiplexer>(
    ConnectionMultiplexer.Connect(builder.Configuration.GetConnectionString("Redis")));

// appsettings.json
{
  "ConnectionStrings": {
    "Redis": "localhost:6379,abortConnect=false"
  }
}

6.4 String 操作

public class RedisCacheService
{
    private readonly IDatabase _db;

    public RedisCacheService(IConnectionMultiplexer redis)
    {
        _db = redis.GetDatabase();
    }

    // 设置值
    public async Task SetAsync(string key, string value, TimeSpan? expiry = null)
    {
        await _db.StringSetAsync(key, value, expiry);
    }

    // 获取值
    public async Task<string?> GetAsync(string key)
    {
        return await _db.StringGetAsync(key);
    }

    // 设置对象（序列化为 JSON）
    public async Task SetObjectAsync<T>(string key, T obj, TimeSpan? expiry = null)
    {
        var json = JsonSerializer.Serialize(obj);
        await _db.StringSetAsync(key, json, expiry);
    }

    // 获取对象
    public async Task<T?> GetObjectAsync<T>(string key)
    {
        var value = await _db.StringGetAsync(key);
        if (value.IsNull) return default;
        return JsonSerializer.Deserialize<T>(value!);
    }

    // 删除
    public async Task DeleteAsync(string key)
    {
        await _db.KeyDeleteAsync(key);
    }

    // 是否存在
    public async Task<bool> ExistsAsync(string key)
    {
        return await _db.KeyExistsAsync(key);
    }

    // 设置过期时间
    public async Task ExpireAsync(string key, TimeSpan expiry)
    {
        await _db.KeyExpireAsync(key, expiry);
    }
}

6.5 Hash 操作

// 存储用户信息
public class UserRedisService
{
    private readonly IDatabase _db;

    public UserRedisService(IConnectionMultiplexer redis) => _db = redis.GetDatabase();

    public async Task SetUserAsync(int userId, string name, int age, string email)
    {
        var key = $"user:{userId}";
        await _db.HashSetAsync(key, new HashEntry[]
        {
            new("name", name),
            new("age", age),
            new("email", email)
        });
        await _db.KeyExpireAsync(key, TimeSpan.FromHours(24));
    }

    public async Task<Dictionary<string, string>> GetUserAsync(int userId)
    {
        var key = $"user:{userId}";
        var entries = await _db.HashGetAllAsync(key);
        return entries.ToDictionary(
            e => e.Name.ToString(),
            e => e.Value.ToString());
    }

    public async Task<string?> GetUserFieldAsync(int userId, string field)
    {
        return await _db.HashGetAsync($"user:{userId}", field);
    }

    public async Task IncrementUserAgeAsync(int userId)
    {
        await _db.HashIncrementAsync($"user:{userId}", "age");
    }
}

6.6 Sorted Set 操作

public class LeaderboardService
{
    private readonly IDatabase _db;

    public LeaderboardService(IConnectionMultiplexer redis) => _db = redis.GetDatabase();

    // 更新分数
    public async Task UpdateScoreAsync(string userId, double score)
    {
        await _db.SortedSetAddAsync("leaderboard", userId, score);
    }

    // 增加分数
    public async Task AddScoreAsync(string userId, double increment)
    {
        await _db.SortedSetIncrementAsync("leaderboard", userId, increment);
    }

    // 获取 TOP N（降序）
    public async Task<List<LeaderboardEntry>> GetTopNAsync(int count)
    {
        var entries = await _db.SortedSetRangeByRankWithScoresAsync(
            "leaderboard", 0, count - 1, Order.Descending);

        return entries.Select((e, i) => new LeaderboardEntry
        {
            Rank = i + 1,
            UserId = e.Element.ToString(),
            Score = e.Score
        }).ToList();
    }

    // 获取用户排名
    public async Task<long> GetRankAsync(string userId)
    {
        return await _db.SortedSetRankAsync("leaderboard", userId, Order.Descending) + 1;
    }
}

七、Key 命名规范

格式：业务:实体:标识

示例：
  user:1                     — 用户信息
  user:1:profile             — 用户详细资料
  cache:product:100          — 商品缓存
  session:token:abc123       — Session
  lock:order:12345           — 分布式锁
  leaderboard:daily:20260531 — 排行榜
  queue:email                — 邮件队列

原则：
  - 用冒号分隔层级
  - 简短有意义
  - 避免特殊字符
  - 统一前缀方便管理

八、小结

本文学习了 Redis 的基础：

Redis 是什么和为什么快
5 种核心数据类型（String、Hash、List、Set、Sorted Set）
其他类型（Bitmap、HyperLogLog、Stream）
通用命令
.NET 客户端 StackExchange.Redis
Key 命名规范

下一篇将学习缓存实战：缓存模式、过期策略和三大经典问题。