---
tags: [Redis, 缓存, 运维, 性能调优]
create time: 2026-05-15 18:16
---

# Redis 运维与性能调优

## 概述

你把 Redis 装好、数据灌进去、代码跑通了——然后呢？

想象一下：某天凌晨 3 点，告警响了，接口 P99 从 2ms 飙到 2 秒。你登上服务器一看，Redis 进程还活着，`redis-cli ping` 也返回 PONG，但业务就是慢。问题出在哪？**如果你不知道该看哪些指标、不知道大 Key 的危害、不知道连接池怎么配，你只能靠猜。**

本节就是帮你建立"Redis 运维直觉"——从监控什么、怎么看，到常见问题怎么治。内容按照"先能发现问题 → 再会分析问题 → 最后能解决问题"的顺序组织。

## 一、监控指标体系

> [!QUESTION] 面试中常被问到：你怎么监控线上的 Redis？
> 一个好的回答不是背出 `INFO` 命令的所有字段，而是说出"我关注哪几个指标、为什么关注、异常了怎么处理"。这一节帮你建立这个体系。

### INFO 命令分级

```bash
# ──── 核心指标 ────
INFO server          # 版本、进程 ID、启动时间、运行天数
INFO clients         # 连接数、阻塞客户端数、写入缓冲区
INFO memory          # 内存使用量、峰值、碎片率 ← **必看**
INFO stats           # 命中率、命令数、fork 耗时 ← **必看**
INFO persistence     # RDB/AOF 状态 ← **必看**
INFO replication     # 主从关系、延迟 ← **必看**
INFO commandstats    # 各命令调用量和耗时排名

# ──── 辅助指标 ────
INFO keyspace        # 每个 DB 的 key 数量和 TTL 统计
INFO cpu             # CPU 消耗
INFO errorstats      # 错误统计
INFO cluster         # 集群拓扑（仅 Cluster）
INFO sentinel        # Sentinel 信息（仅 Sentinel）
```

### 关键指标解读

```bash
# 从 INFO stats 提取的核心指标
keyspace_hits: 987654       # 缓存命中次数
keyspace_misses: 12346      # 缓存未命中次数
# → 命中率 = 987654 / (987654 + 12346) = 98.76%

used_memory_human: 1.23G    # 已用内存
used_memory_rss_human: 1.35G # OS 分配给 Redis 进程的物理内存（含碎片）
mem_fragmentation_ratio: 1.09 # used_memory_rss / used_memory = 碎片率
```

**指标详解：**

- **命中率** = `keyspace_hits / (keyspace_hits + keyspace_misses)`：请求在 Redis 中找到目标 Key 的比例。命中率低于 80% 说明缓存层未能有效拦截请求，大量请求直接打到后端数据库。排查方向：TTL 是否设太短、热点 Key 是否分布不均、缓存预热是否已执行。
- **mem_fragmentation_ratio** = `used_memory_rss / used_memory`：操作系统为 Redis 分配的物理内存（RSS）与 Redis 自身申请的内存之比。**> 1.5** 表示内存碎片严重，物理内存浪费明显，建议开启 `activedefrag`；**< 1.0** 表示 RSS 小于申请量，说明操作系统将部分 Redis 内存换出到了磁盘（swap），访问时会产生磁盘 I/O，延迟从微秒级飙升到毫秒甚至秒级。
- **rejected_connections**：被 Redis 拒绝的连接数。正常值始终为 0；一旦大于 0，说明当前连接数已超过 `maxclients` 上限，需要调大该配置或排查连接泄漏问题。
- **total_commands_processed**：Redis 累计处理的命令总数，除以运行秒数可得平均 QPS；也可直接查看 `instantaneous_ops_per_sec` 获取实时 QPS。数值平稳增长说明服务正常；若突然断崖式下跌，通常是主线程被阻塞所致，常见原因包括大 Key 操作、fork 子进程、AOF fsync 等。
- **connected_slaves**：当前连接的从节点数量。例如配了一主两从，此处应为 2；若变为 0，说明所有副本失联，读写分离和高可用机制均失效，需立即排查主从复制链路。

> [!QUESTION] 碎片率 1.2 和 0.8，哪个更危险？
> 很多人直觉会觉得 1.2（碎片多）更严重，但实际上 **0.8 才是最危险的信号**——它意味着 Redis 进程的内存已经被操作系统换出到磁盘（swap），性能会断崖式下降。碎片高只是浪费内存，swap 却是"要命"的事。

### 健康标准速查

| 指标 | 正常范围 | 警告阈值 |
|------|---------|---------|
| 命中率 | > 90% | < 80% 需排查 |
| mem_fragmentation_ratio | 1.0 ~ 1.5 | > 1.5 内存浪费，< 1.0 swap 风险 |
| rejected_connections | 0 | > 0 说明 maxclients 不够 |
| total_commands_processed/s | 平稳增长 | 断崖式下跌说明异常 |
| connected_slaves | ≥ 预期 | 0 = 全部分离 |

### 副本延迟监控

```bash
# 从节点查看主从状态
INFO replication
# role:slave / master_host / master_port / master_link_status(up/down)
# master_last_io_seconds_ago, master_sync_in_progress

# 关键指标：master_repl_offset - slave_repl_offset
# → 差值即为延迟字节数，超过 1MB 需关注
```

> [!WARNING] 副本延迟常见原因
> - **单线程写放大**：主库高并发写入时，从库网络 IO 成为瓶颈
> - **大 Key 持久化**：BGSAVE/BGREWRITEAOF 期间从库全量同步会短暂中断服务
> - **解决方案**：配置多个从库分担读取流量 + 使用 `replica-read-only yes`（Redis 5.0+）禁止从库写入

### 实时监控脚本

```bash
#!/bin/bash
HOST=${1:-127.0.0.1}
PORT=${2:-6379}

echo "=== Memory ==="
redis-cli -h $HOST -p $PORT INFO memory \
  | grep -E "used_memory_human|maxmemory_human|mem_fragmentation_ratio"

echo "=== Stats ==="
redis-cli -h $HOST -p $PORT INFO stats \
  | grep -E "keyspace_hits|keyspace_misses|instantaneous_ops_per_sec"

echo "=== Clients ==="
redis-cli -h $HOST -p $PORT INFO clients \
  | grep -E "connected_clients|blocked_clients"

echo "=== Persistence ==="
redis-cli -h $HOST -p $PORT INFO persistence \
  | grep -E "aof_enabled|rdb_last_bgsave_status"
```

## 二、慢查询日志

上一节的监控指标能告诉你"Redis 整体状态如何"，但如果你想定位"**是哪条命令拖慢了 Redis**"，就需要慢查询日志了。它的原理很简单：Redis 在主线程执行每条命令，如果某条命令的执行时间超过阈值，就记录下来。

> [!QUESTION] 慢查询日志 vs 应用日志？
> 应用日志记录的是"你的代码花了多久调用 Redis"（包含网络延迟、序列化开销），慢查询日志记录的是"Redis 服务端执行这条命令本身花了多久"。两者差异越大，说明问题越可能出在网络或客户端。

### 配置与分析

```bash
# 默认配置
CONFIG GET slowlog-log-slower-than    # 默认 10000 μs (10ms)
CONFIG GET slowlog-max-len            # 默认 128 条

# 调整为 5ms 阈值
CONFIG SET slowlog-log-slower-than 5000

# 扩大存储容量
CONFIG SET slowlog-max-len 2048

# 查看慢查询
SLOWLOG GET 10

# 重置
SLOWLOG RESET
```

### 典型慢查询根因

| 慢查询 | 根因 | 修复方案 |
|--------|------|---------|
| `KEYS *` | 全库扫描 O(N) | 改用 SCAN |
| `HGETALL large_hash` | 大 Hash 全量返回 | HSCAN 分页 |
| `SMEMBERS huge_set` | 大集合全量遍历 | SSCAN 分页 |
| `LRANGE 0 -1` (百万条 List) | 全列表拉取 | LRANGE 指定范围 |
| 无索引的 DB 查询（在 Lua 中） | DB 层问题 | 加 DB 索引 |

```bash
# SLOWLOG GET 输出字段说明
1) (integer) 14              # 慢查询 ID（递增）
2) (integer) 1716620400      # 发生时间（Unix 时间戳）
3) (integer) 13456           # 耗时（微秒）
4) 1) "KEYS"                 # 命令及参数
   2) "*"
5) "127.0.0.1:53412"         # 客户端地址
6) ""                        # 客户端名称
```

```go
// go-redis 中的 SlowLog 接口
entries, err := rdb.SlowLogGet(ctx, 10).Result()
if err != nil {
    log.Fatal(err)
}
for _, e := range entries {
    fmt.Printf("ID: %d, Time: %s, Cmd: %s, Duration: %v\n",
        e.ID, e.Time.Format(time.RFC3339), e.Args, e.Duration)
}
```

### 延迟诊断工具

Redis 提供了内建的延迟诊断能力，定位"客户端感知慢"但服务端 CPU 并不繁忙的场景：

```bash
# ──── 实时延迟采样（排查首选） ────
redis-cli --latency                    # 持续输出 min/avg/max（ms）
redis-cli --latency-history -i 5       # 每 5 秒输出一次统计

# ──── 延迟分布直方图 ────
redis-cli --latency-dist               # 交互式彩色直方图，快速定位延迟区间

# ──── 事件驱动延迟监控（需服务端配置） ────
# 在 redis.conf 中配置延迟阈值（微秒）
# latency-monitor-threshold 10

# 之后查看：
LATENCY LATEST              # 最近的延迟事件
LATENCY HISTORY command     # 某命令的延迟历史
LATENCY RESET               # 重置统计数据
```

> [!TIP] 延迟排查三板斧
> 1. `redis-cli --latency` — 先看基线是否正常（正常 P99 < 1ms）
> 2. `LATENCY LATEST` — 看是否有异常事件（fork、大 Key 删除、AOF fsync）
> 3. `INFO commandstats` — 按命令耗时排序，定位慢命令

## 三、大 Key 治理

如果慢查询是"某一顿饭做得太慢"，大 Key 就是"你端了一整头牛上来"——不管厨师多快，处理这道菜都要比小菜慢得多。而且大 Key 不光影响自己，还会堵住后面所有命令（因为 Redis 是单线程的）。

### 什么是大 Key？

简单说就是 value **太大**的 Key。业界的经验阈值：**字符串 value ≥ 1MB**，**集合类（Hash / Set / ZSet / List）元素数 > 5000 或总大小 > 10MB**。

> [!QUESTION] 大 Key 是怎么产生的？
> 大多数大 Key 不是一开始就设计成这样的，而是"长"出来的——比如一个 List 本来只有几十条记录，业务不断 append 从不清理，半年后变成几百万条。这就像你家阳台的杂物间，"就放一点"，最后堆满了。

> [!WARNING] 大 Key 的危害
> - **网络阻塞**：SET/GET 一个 1MB 的值占满一条 TCP 连接
> - **过期事件堆积**：大量大 key 同时过期时一次性触发删除，阻塞主线程
> - **分片迁移卡顿**：Cluster 迁移 slot 时需要复制整个值
> - **RDB/AOF 膨胀**：持久化文件急剧增大

### 检测工具

发现大 Key 有多种方式，从轻到重依次是：

```bash
# 方式 1: redis-cli --bigkeys（按元素数量采样扫描）
redis-cli --bigkeys -n 1000

# 输出示例：
# --- SUMMARY ---
# Size       Count  Type        Keys
# 1.23MB     1      string      user:avatar:big_image
# 456KB      3      hash        order:items:*
# ...

# 方式 2: redis-cli --memkeys（按实际内存占用扫描，更精确）
redis-cli --memkeys -n 1000
# → 会输出每个 key 的内存大小（字节），适合发现大 value 的 string key

# 方式 3: redis-rdb-tools（RDB 离线分析，最全面）
rdb -c memory dump.rdb | sort -k2 -rn | head -20

# 方式 4: RedisInsight / AnotherRedisDesktopManager GUI
```

> [!NOTE] --bigkeys vs --memkeys
> - `--bigkeys`：按**元素数量**排序，擅长发现超大 Hash / Set / ZSet
> - `--memkeys`：按**实际内存占用**排序，能精准发现大 value 的 String key
> - 两者都基于 SCAN，不会阻塞生产环境；建议配合使用覆盖所有场景

### 拆分策略

核心思路：**把一头牛切成小块上桌**。常见的拆分方式是按业务维度分片：

```
原始大 Key:
order:12345 -> hash{ item1, item2, ..., item5000 }  ← 5000 个订单项塞在一个 Hash 里

拆分后:
order:12345:meta  -> hash{ status, amount, ... }     ← 订单元数据（小）
order:12345:items:0 -> list[ item1~item100 ]         ← 按 100 个一组分片
order:12345:items:1 -> list[ item101~item200 ]
...

读取时先读 meta，再按需读取对应分片——大多数场景只需要第一页数据
```

### DEL 大 Key 的风险

```bash
# ⛔ 直接 DEL 大 key 会阻塞主线程！
DEL big_key

# ✅ 渐进式删除（SCAN + UNLINK）
UNLINK big_key        # 异步删除（Redis 4.0+），立即返回
                        # 后台线程回收内存
```

> [!TIP] UNLINK vs DEL
> - `DEL`：同步删除，大 key 可能阻塞数十毫秒甚至秒级
> - `UNLINK`：异步删除，立即返回，后台回收（类似 GC）
> - 生产环境优先使用 `UNLINK`

## 四、连接池调优

### 为什么需要连接池？

没有连接池时，每个请求都要"三次握手 → 发命令 → 四次挥手"——就像每次去银行都要重新取号、排队、开户。连接池相当于你开了个 VIP 账户，提前建好一批连接"待命"，请求来了直接复用，用完归还。

```mermaid
flowchart LR
    subgraph APP["应用进程"]
        G1["Goroutine 1"] --> Pool["连接池"]
        G2["Goroutine 2"] --> Pool
        G3["Goroutine 3"] --> Pool
    end
    subgraph POOL["连接池内部"]
        C1["连接 1 (忙碌)"]
        C2["连接 2 (空闲)"]
        C3["连接 3 (空闲)"]
    end
    Pool --> POOL
    POOL --> Redis["Redis Server"]

    style C1 fill:#fdd,stroke:#900
    style C2 fill:#dfd,stroke:#090
    style C3 fill:#dfd,stroke:#090
```

> [!QUESTION] 连接池设多大才合适？
> 不是越大越好。每个连接都要占一个文件描述符和内存。连接太多 = 排队的人比窗口多，反而增加上下文切换开销。一般的经验值：**PoolSize = CPU 核心数 × 2 ~ 5**，大多数 Web 应用 50~100 就够了。

### Go go-redis 连接池配置

```go
rdb := redis.NewClient(&redis.Options{
    Addr:     "localhost:6379",
    Password: "",
    DB:       0,

    // ──── 连接池参数（go-redis v9） ────
    // 类比：连接池就像餐厅的桌子——PoolSize 是最大桌数，MinIdleConns 是
    // 每天开业前至少要摆好的桌子数，ConnMaxIdleTime 是桌子空闲多久后收掉
    PoolSize:        100,              // 最多同时维持 100 个连接（并发 Goroutine 很多时调大）
    MinIdleConns:    10,               // 启动时预先建 10 个连接，避免冷启动延迟
    ConnMaxIdleTime: 5 * time.Minute,  // 空闲超过 5 分钟的连接自动关闭，释放资源
    ConnMaxLifetime: 0,                // 连接最大存活时间，0 = 不限制（通常保持默认即可）

    // ──── 超时参数 ────
    // 这些超时是你的"止损线"——如果 Redis 出问题，最多等多久就放弃
    DialTimeout:  5 * time.Second,     // 建连超时：Redis 宕机时不会永远卡住
    ReadTimeout:  3 * time.Second,     // 读超时：普通命令 3s 足够，大 Key 操作需调大
    WriteTimeout: 3 * time.Second,     // 写超时：同上
    PoolTimeout:  1 * time.Second,     // 从池里拿连接的等待时间：超时说明池子太小或 Redis 慢

    // ──── 重试策略 ────
    MaxRetries:      3,                // 最多重试 3 次（网络抖动时自动恢复）
    MinRetryBackoff: 200 * time.Millisecond, // 第一次重试等 200ms
    MaxRetryBackoff: 1 * time.Second,        // 最长等 1s（指数退避，不会一直刷）
})
```

> [!NOTE] go-redis v8 → v9 参数变化
> - `MaxIdle` / `MaxActive` → 合并为 `PoolSize`，`MinIdleConns` 控制预热
> - `IdleTimeout` → `ConnMaxIdleTime`
> - `PingPeriod` 无对应字段，go-redis 内部通过健康检查自动保活
> - `RetryDelay` → `MinRetryBackoff` + `MaxRetryBackoff`（指数退避）

### 连接池选型决策树

```mermaid
flowchart TD
    A["预估 QPS"] -->|"< 500"| S["PoolSize: 20, MinIdleConns: 5"]
    A -->|"500 ~ 5000"| M["PoolSize: 50, MinIdleConns: 20"]
    A -->|"\> 5000"| L["PoolSize: 100\~200, MinIdleConns: 30~50"]

    B{"有无 Pipeline?"}
    B -->|"是"| C["增加 30% 连接数"]
    B -->|"否"| D["保持上述配置"]

    style L fill:#fdd,stroke:#900
```

> [!TIP] PoolSize 计算公式
> ```
> PoolSize = N × (1 + CPU等待时间/CPU计算时间)
> ```
> 其中 N 为 Goroutine 数量。对于大多数 Web 应用，**50~100** 已经足够——如果频繁出现 PoolTimeout，优先考虑排查慢查询或大 Key 问题。

> [!WARNING] 连接池常见问题
> - **PoolSize 太小**：`context deadline exceeded`（PoolTimeout）频繁出现
> - **PoolSize 太大**：创建过多 TCP 连接，文件描述符耗尽
> - **ReadTimeout 太短**：大数据量操作（如 HGETALL 大 hash）被误杀
> - **不设 DialTimeout**：Redis 宕机时请求永远挂起

## 五、内存管理与淘汰策略

前面讲了怎么发现大 Key、怎么配置连接池，现在来说说一个更根本的问题：**Redis 内存用完了怎么办？**

打个比方：你的 Redis 就像一个固定大小的冰箱。`maxmemory` 是冰箱的容量，淘汰策略决定了"新菜放不下的时候，扔掉哪道旧菜"。

### maxmemory 设置

```conf
maxmemory 2gb
maxmemory-policy allkeys-lru
```

### 淘汰策略详解

> [!QUESTION] 没有永不超限的策略？
> 如果你不想丢数据，可以设 `noeviction`——但代价是写操作会直接报错。就像冰箱满了还硬塞，食物会掉地上。更好的做法是：**合理设置 maxmemory + 选择合适的淘汰策略**，提前决定"扔哪道菜"。

**淘汰策略选型——该扔哪道菜？**

```mermaid
flowchart TD
    Start["冰箱满了, 该扔哪道菜?"] --> Q1{"所有数据都能丢吗?"}
    Q1 -->|"不能丢, 如配置中心"| Noevict["noeviction<br/>满了就报错, 不扔"]
    Q1 -->|"可以丢"| Q2{"数据都设了 TTL 吗?"}
    Q2 -->|"是, 都可以过期"| TTL["volatile-ttl<br/>优先扔最快过期的"]
    Q2 -->|"否, 混合存储"| Q3{"访问频率差异大吗?<br/>二八定律明显"}
    Q3 -->|"是, 有明显冷热分离"| LFU["allkeys-lfu<br/>优先扔访问次数最少的"]
    Q3 -->|"否, 访问比较均匀"| LRU["allkeys-lru<br/>优先扔最久没被访问的, 默认推荐"]

    style LRU fill:#dfd,stroke:#090
    style Noevict fill:#fdd,stroke:#900
```

完整策略对照：

| 策略 | 作用范围 | 淘汰算法 | 适用场景 |
|------|---------|---------|---------|
| **allkeys-lru** | 所有 key | LRU（近似） | 通用缓存 ✅ **最常用，拿不准就选它** |
| allkeys-lfu | 所有 key | LFU（频次统计） | Redis 4.0+，热点数据语义更强的场景 |
| volatile-lru | 仅设 TTL 的 key | LRU（近似） | 混合存储：永不过期的配置 + 可淘汰的缓存 |
| volatile-lfu | 仅设 TTL 的 key | LFU（频次统计） | 混合存储 + 频次敏感淘汰 |
| volatile-ttl | 仅设 TTL 的 key | TTL 最短优先 | 让数据自然过期的场景 |
| noeviction | — | — | 数据不可丢失，满了返回错误（如配置中心） |

> [!NOTE] LRU vs LFU——"最久没用" vs "最少被用"
> - **LRU**（Least Recently Used）：图书馆里"最久没被借走的书先下架"。只要最近被借过就不会被淘汰，哪怕只借了一次。实现简单，内存开销小。
> - **LFU**（Least Frequently Used）：图书馆里"被借次数最少的书先下架"。一本冷门书即使昨天刚被借过，如果历史总次数少也可能被淘汰。每 key 多消耗 16 bits 记录频率，更精准但略贵。
> - **实际选型**：不确定就先用 `allkeys-lru`；如果存在明显"二八定律"（20% 数据占 80% 访问），`allkeys-lfu` 更合理。

### 内存碎片治理

什么是碎片？想象你往书架上放书、取书，取走后留下空隙。时间久了，书架明明有空位，但因为每段空位都太小，新书放不进去——这就是碎片。

```bash
# 查看碎片率（来自 INFO memory 输出）
# mem_fragmentation_ratio = used_memory_rss / used_memory
# 正常范围: 1.0 ~ 1.5

# 配置激活在线碎片整理（Redis 4.0+，仅在 Linux 上有效）
# 相当于请了一个"图书管理员"，后台慢慢把书架缝隙整理好
activedefrag yes
active-defrag-threshold-lower 10    # 碎片率 > 10% 时启动整理
active-defrag-threshold-upper 50    # 碎片率 > 50% 时全力整理（CPU 占用也会升高）
active-defrag-cycle-min 5           # 每次整理最多占 CPU 5%（不影响正常服务）
active-defrag-cycle-max 25          # 全力整理时最高占 CPU 25%
```

> [!QUESTION] 为什么 fragmentation ratio < 1.0？
> 表示 RSS < used_memory——这意味着发生了 **swap**。操作系统把 Redis 的物理内存换出到磁盘，灾难性后果——延迟飙升到秒级。
> 
> ```bash
> # 检查是否开启了 swap
> free -m
> # 如果 swapped > 0 → 立即处理！
> ```

## 六、备份与灾难恢复

> [!QUESTION] Redis 需要备份吗？不是有主从复制吗？
> 主从复制能防"机器挂了"，但防不了"误删数据"。如果有人执行了 `FLUSHALL`，这个命令会同步到所有从库——数据瞬间全没了。**备份是最后一道防线。**

### 定时备份方案

```bash
#!/bin/bash
# backup.sh — 每天凌晨 2 点执行
BACKUP_DIR="/backup/redis"
DATE=$(date +%Y%m%d_%H%M%S)

# 触发 BGSAVE
redis-cli BGSAVE

# 等待完成（轮询 LASTSAVE）
sleep 5
cp /var/lib/redis/dump.rdb "$BACKUP_DIR/dump_$DATE.rdb"
gzip "$BACKUP_DIR/dump_$DATE.rdb"

# 保留最近 30 天的备份
find $BACKUP_DIR -mtime +30 -delete

# 上传到对象存储
aws s3 cp "$BACKUP_DIR/dump_$DATE.rdb.gz" "s3://your-bucket/redis-backup/"
```

Crontab:
```
0 2 * * * /path/to/backup.sh >> /var/log/redis-backup.log 2>&1
```

### 灾难恢复流程

```mermaid
flowchart TD
    A["数据异常或丢失"] --> B{"可用最近的备份?"}
    B -->|"是"| C["停止写入，防止覆盖"]
    C --> D["恢复 RDB/AOF 备份"]
    D --> E["检查数据完整性"]
    E --> F{"数据是否完整?"}
    F -->|"是"| G["恢复写入，观察指标"]
    F -->|"否"| H{"有增量日志?"}
    H -->|"AOF"| I["附加修复 AOF 文件<br/>redis-check-aof --fix"]
    H -->|"无"| J["从主库全量同步"]
    I --> E
    J --> E
    B -->|"否"| K["从主库重新同步"]
    K --> E
    
    style A fill:#fdd,stroke:#900
    style G fill:#dfd,stroke:#090
```

### 云厂商迁移工具

| 来源 | 目标 | 工具 |
|------|------|------|
| 自建 Redis | AWS ElastiCache | `elasticache-migration-tool` |
| 自建 Redis | Aliyun ApsaraDB | `redis-shake` |
| Redis Cluster | 云 Redis | 云控制台导入功能 |
| Redis to Redis | 任意 | `redis-shake` |

## 七、安全加固清单

Redis 默认配置是"裸奔"的——没有密码、绑定所有网卡、所有命令都能执行。上线前必须加固，就像搬进新家要换锁、装窗帘一样。

> [!todo] 生产环境安全核对
> - [ ] `requirepass` 已设置强密码
> - [ ] `rename-command FLUSHALL ""` — 重命名危险命令（或设为空禁用）
> - [ ] `rename-command DEBUG ""` — 禁用 debug 命令
> - [ ] 绑定内网 IP 而非 `0.0.0.0`
> - [ ] TLS/SSL 加密传输（Redis 6.0+ 支持）
> - [ ] 定期更新版本号，修复已知 CVE
> - [ ] ACL 用户权限控制（Redis 6.0+ 支持多用户角色）

> [!WARNING] rename-command 已在 Redis 6.2+ 中废弃
> 新版本推荐使用 **ACL** 精细控制每个用户的命令权限（见下方示例），`rename-command` 仅作为旧版本的兼容方案保留。新建项目应直接使用 ACL。

```bash
# ACL 示例（Redis 6.0+）
ACL SETUSER readonly on >readOnlyPass123 ~cached:* &* +get +mget +scan +ping
ACL SETUSER writer on >writePass123 ~* &* +set +hset +lpush +sadd +incr +del +ping
ACL LIST   # 查看所有用户
ACL WHOAMI # 当前用户
```

## 八、性能基准测试

> [!QUESTION] 为什么要跑压测？调完参数凭感觉不行吗？
> 不行。没有数据的调优就是瞎猜。压测的价值在于：**给你一个基线数字**，之后所有优化都能对比。"改了连接池大小后 QPS 从 5 万涨到 8 万"——这才是有说服力的调优。

`redis-benchmark` 是 Redis 自带的压测工具，不需要安装任何依赖，能快速摸底单实例或集群的吞吐上限。把它想成"给 Redis 做体检"——先测一下各项指标的正常值，之后才知道哪里不好。

### 常用命令

```bash
# ──── 基础测试（100 并发，50 请求，只测 SET/GET） ────
redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 50000 -t set,get

# ──── 模拟真实 Pipeline 场景 ────
redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -P 16 -t set,get
# -P 16 表示每个连接一次发 16 条命令（Pipeline），大幅提升吞吐

# ──── 测试特定命令和数据大小 ────
redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 50000 \
  -t set,get \
  -d 256 \        # value 大小 256 bytes（默认 3 bytes，偏小）
  -r 100000 \     # 使用 10 万个随机 key，避免热点
  --csv           # CSV 输出，方便脚本采集
```

### 输出字段解读

```
====== SET ======
  50000 requests completed in 0.45 seconds   ← 总耗时
  100 parallel clients                       ← 并发数
  3 bytes payload                            ← 数据大小
  keep alive: 1                              ← 长连接
  multi-thread: no                           ← 单线程模式

111111.11 requests per second               ← 吞吐量（QPS）
Latency by percentile distribution:
0.000% <= 0.103 milliseconds               ← P0（最快）
50.000% <= 0.199 milliseconds               ← P50
99.000% <= 0.511 milliseconds               ← P99
99.900% <= 0.831 milliseconds               ← P999
100.000% <= 1.247 milliseconds              ← P100（最慢）
```

> [!TIP] 压测注意事项
> - **别在生产环境跑**：压测会把 Redis 跑满，影响线上请求
> - **-r 参数很重要**：默认所有请求打同一个 key，数据不真实；加 `-r` 让 key 随机化
> - **-d 参数要贴近真实**：默认 3 bytes，你的业务 value 可能是几百字节到几 KB，差异很大
> - **Pipeline 是最大加速器**：`-P 16` 可以让 QPS 提升 5~10 倍，生产环境务必启用 Pipeline

### Go 应用中的压测替代方案

```go
// 用 vegeta 或 wrk 压测你的 HTTP 接口，比 redis-benchmark 更贴近真实场景
// redis-benchmark 只测 Redis 本身，不包含：连接池等待、序列化开销、业务逻辑

// 如果想精确测 go-redis 连接池表现，可以用 benchmark 测试函数：
func BenchmarkRedisSet(b *testing.B) {
    rdb := redis.NewClient(&redis.Options{Addr: "localhost:6379"})
    defer rdb.Close()
    ctx := context.Background()

    b.ResetTimer()
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            rdb.Set(ctx, "bench:key", "value", 0)
        }
    })
}
```

> [!NOTE] redis-benchmark vs 应用级压测
> - `redis-benchmark`：测 Redis **服务端极限吞吐**，排除网络因素，适合摸底
> - 应用级压测（vegeta / wrk / k6）：测**端到端链路**，包含连接池、序列化、业务逻辑，更贴近真实
> - 建议两者结合：先用 `redis-benchmark` 确认 Redis 本身没问题，再用应用级压测定位瓶颈

## 关联笔记

- [[hhs/Redis/04-RDB持久化]] — RDB 快照与备份
- [[hhs/Redis/05-AOF持久化]] — AOF 文件大小管理
- [[hhs/Redis/06-主从与哨兵]] — 主从复制与 Sentinel 高可用
- [[hhs/Redis/07-集群方案]] — 集群运维注意事项
- [[hhs/Redis/10-缓存架构模式]] — 缓存策略与淘汰策略选型
- [[hhs/Redis/README]] — 知识索引总览