# 持续 PING 并统计延迟（毫秒）
$ redis-cli --latency
min: 0, max: 3, avg: 0.11 (1429 samples)

# 按 15 秒区间输出历史（观察趋势和毛刺）
$ redis-cli --latency-history
min: 0, max: 2, avg: 0.10 (1435 samples) -- 15.01 seconds range
min: 0, max: 87, avg: 0.35 (1201 samples) -- 15.00 seconds range   ← 有毛刺！

# 延迟分布彩色图（看长尾）
$ redis-cli --latency-dist

# 在【Redis 所在的机器上】运行，跑 100 秒
$ redis-cli --intrinsic-latency 100
Max latency so far: 1 microseconds.
Max latency so far: 15 microseconds.
Max latency so far: 3120 microseconds.       ← 3ms！机器本身有问题
...
Max latency so far: 3120 microseconds.
1957014 total runs (avg latency: 0.0510 microseconds / 51.02 nanoseconds per run).
Worst run took 61154x longer than the average latency.

redis-cli CONFIG SET latency-monitor-threshold 100

# 查看有哪些延迟事件
127.0.0.1:6379> LATENCY LATEST
1) 1) "command"              # 事件类型
   2) (integer) 1785657600   # 最近一次发生的时间戳
   3) (integer) 350          # 最近一次的延迟（毫秒）
   4) (integer) 1200         # 【历史最大延迟】
2) 1) "fork"
   2) (integer) 1785657500
   3) (integer) 180
   4) (integer) 450

# 查看某个事件的历史（最多 160 个样本）
127.0.0.1:6379> LATENCY HISTORY command

# 【非常有用】生成一份人类可读的延迟诊断报告
127.0.0.1:6379> LATENCY DOCTOR
Dave, I have observed latency spikes in this Redis instance.
You don't mind talking about it, do you Dave?

1. command: 12 latency spikes (average 350ms, mean deviation 120ms,
   period 45.20 sec). Worst all time event 1200ms.

I have a few advices for you:
- Check your Slow Log to understand what are the commands you are running
  which are too slow to execute. ...

127.0.0.1:6379> LATENCY RESET       # 清空

redis-cli CONFIG SET slowlog-log-slower-than 5000    # 排查时可以调到 5ms
redis-cli CONFIG SET slowlog-max-len 1000

127.0.0.1:6379> SLOWLOG GET 5
1) 1) (integer) 14              # 唯一 ID
   2) (integer) 1785657600      # 发生时间戳
   3) (integer) 152300          # 【耗时：微秒】= 152ms
   4) 1) "HGETALL"              # 命令及参数
      2) "user:big:hash"
   5) "10.0.0.9:52133"          # 客户端地址
   6) "order-service-1"         # 客户端名字（CLIENT SETNAME 设置的）

127.0.0.1:6379> SLOWLOG LEN
127.0.0.1:6379> SLOWLOG RESET

127.0.0.1:6379> INFO commandstats
cmdstat_get:calls=1000000,usec=1500000,usec_per_call=1.50,rejected_calls=0,failed_calls=0
cmdstat_hgetall:calls=1000,usec=15000000,usec_per_call=15000.00,...
#                     ↑ 只调用 1000 次        ↑ 但总耗时 15 秒！平均 15ms
cmdstat_keys:calls=5,usec=8000000,usec_per_call=1600000.00,...
#                                  ↑ 平均 1.6 秒！

# 6.2+ 还有延迟百分位分布
127.0.0.1:6379> INFO latencystats
latency_percentiles_usec_get:p50=1.003,p99=3.007,p99.9=8.031
latency_percentiles_usec_hgetall:p50=1200.5,p99=45000.0,p99.9=180000.0

# 重置统计（做基线对比时用）
127.0.0.1:6379> CONFIG RESETSTAT

# 按总耗时排序，找出占用时间最多的命令
redis-cli INFO commandstats | \
  sed 's/cmdstat_//' | \
  awk -F'[:,=]' '{print $6, $2}' | sort -rn | head -10
#                    ↑usec  ↑命令名

# 类似 top，每秒刷新核心指标
$ redis-cli --stat
------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections
1000000    1.20G    52      0       12345678 (+1234)    5678
1000012    1.20G    52      0       12346912 (+1234)    5678

# 实时打印所有命令（【生产慎用】，官方压测显示吞吐下降 50%+）
$ redis-cli monitor
# 抓一小段样本就 Ctrl+C
$ timeout 5 redis-cli monitor > /tmp/monitor.log

# 统计样本里最频繁的命令和 key
$ awk '{print $4}' /tmp/monitor.log | sort | uniq -c | sort -rn | head -20
$ awk '{print $4, $5}' /tmp/monitor.log | sort | uniq -c | sort -rn | head -20

# 1. 先确认是不是 fork（最常见的毛刺来源）
redis-cli INFO stats | grep latest_fork_usec
# 如果 > 100000（100ms），且毛刺时间点和 bgsave/bgrewriteaof 吻合 → 就是它
redis-cli INFO persistence | grep -E 'rdb_last_save_time|aof_rewrite'

# 2. 看延迟事件记录（最直接）
redis-cli CONFIG SET latency-monitor-threshold 50
# 等待一段时间后
redis-cli LATENCY LATEST
redis-cli LATENCY DOCTOR

# 3. 看是否有周期性的慢命令
redis-cli SLOWLOG GET 100

# 4. 排查系统层
# CPU 是否被抢占
top -H -p $(pgrep -f redis-server)
# 是否在 swap
cat /proc/$(pgrep -f redis-server)/smaps | grep -i swap | awk '{s+=$2} END {print s" kB"}'
# 磁盘 IO 是否饱和
iostat -x 1
# 网络是否有丢包/重传
netstat -s | grep -i retrans
sar -n DEV 1

# 5. 排查是否有其他进程争抢资源
#（常见：同一台机器上跑了多个 Redis 实例，同时 bgsave）

127.0.0.1:6379> MEMORY STATS
 1) "peak.allocated"                      # 历史峰值
 2) (integer) 5368709120
 3) "total.allocated"                     # 当前总分配
 4) (integer) 4294967296
 5) "startup.allocated"                   # 启动时的基础开销（约几 MB）
 7) "replication.backlog"                 # 【复制积压缓冲区】
 9) "clients.slaves"                      # 【从节点客户端缓冲区总和】
11) "clients.normal"                      # 【普通客户端缓冲区总和】
13) "cluster.links"                       # 集群链路缓冲
15) "aof.buffer"                          # AOF 缓冲区
17) "lua.caches"                          # 【Lua 脚本缓存】（动态生成脚本会泄漏）
19) "functions.caches"
21) "db.0"
22)  1) "overhead.hashtable.main"          # 主字典的元数据开销
     3) "overhead.hashtable.expires"       # 【过期字典的开销】（带 TTL 的 key 多时很大）
     5) "overhead.hashtable.slot-to-keys"
...
"overhead.total"                           # 所有非数据开销总和
"keys.count"                               # key 总数
"keys.bytes-per-key"                       # 【平均每个 key 占多少字节】
"dataset.bytes"                            # 纯数据占用
"dataset.percentage"                       # 数据占总内存的比例
"peak.percentage"
"allocator.allocated" / "allocator.active" / "allocator.resident"
"allocator-fragmentation.ratio"            # 【分配器层面的碎片率】（比 mem_fragmentation_ratio 更准）
"fragmentation"                             # 总碎片率

# Redis 自己的诊断建议
127.0.0.1:6379> MEMORY DOCTOR
Sam, I detected a few issues in this Redis instance memory implants:
 * High allocator fragmentation: This instance has an allocator external
   fragmentation greater than 1.1. ...
 * Big keys found: ...

# ---------- 1. 用 hash 代替多个 string key（最有效）----------
# 差：3 个 key，每个都有 robj(16) + dictEntry(32) + key的SDS + value的SDS
SET user:1001:name tom
SET user:1001:age 20
SET user:1001:city beijing
# 好：1 个 key，listpack 编码下每个字段只占几字节
HSET user:1001 name tom age 20 city beijing
# 内存可省 3~5 倍

# ---------- 2. 大 hash 分桶保持 listpack 编码 ----------
# 100 万字段的大 hash（hashtable 编码，每字段 60~90 字节）
# → 拆成 1000 个各 1000 字段的小 hash（listpack 编码，每字段 5~10 字节）
HSET bucket:$(id/1000) $(id%1000) value
CONFIG SET hash-max-listpack-entries 1000    # 配合调大阈值
# 内存可省 5~10 倍（Instagram 的经典优化，第 4 篇）

# ---------- 3. key 名尽量短（但保持可读）----------
# 差：user:information:detail:profile:1001  （35 字节）
# 好：u:d:1001                              （8 字节）
# 1 亿个 key，每个省 27 字节 = 省 2.7GB

# ---------- 4. 整数尽量存整数 ----------
SET count 100                # int 编码，且 0~9999 用共享对象
SET count "100"              # 同样是 int 编码（Redis 会识别）

# ---------- 5. 布尔状态用 Bitmap ----------
SETBIT active:20260729 1001 1     # 1 亿用户只要 12.5MB（第 3 篇）

# ---------- 6. 海量基数统计用 HyperLogLog ----------
PFADD uv:20260729 user1001        # 固定 12KB，误差 0.81%

# ---------- 7. 小整数打包用 Bitfield ----------
BITFIELD counters SET u8 #1001 42  # 1 亿个 u8 计数器只要 100MB

# ---------- 8. 应用层压缩大 value ----------
# JSON 用 gzip/zstd 通常能压到 20%~30%
# 代价：CPU 开销 + 无法在服务端做部分操作

# ---------- 9. 检查并调优编码阈值 ----------
OBJECT ENCODING mykey
CONFIG GET hash-max-listpack-entries
# 如果集合通常在 200~500，可以把阈值调到 512（但不要超过 1000，第 4 篇）

# ---------- 10. 清理无用数据 ----------
# 找出没有 TTL 的 key（可能是忘了设过期的泄漏源）
redis-cli --scan --pattern 'cache:*' | while read k; do
  [ "$(redis-cli TTL "$k")" = "-1" ] && echo "$k"
done

127.0.0.1:6379> INFO memory
used_memory_human:3.85G                # Redis 认为自己用了多少
used_memory_rss_human:5.20G            # 操作系统看到的物理内存
mem_fragmentation_ratio:1.35           # rss / used
allocator_frag_ratio:1.12              # 【分配器层面的碎片率，更准确】
allocator_frag_bytes:412316860
mem_allocator:jemalloc-5.2.1

# 手动让 jemalloc 把空闲页归还给 OS（不是真正的碎片整理，但常常有效）
127.0.0.1:6379> MEMORY PURGE

# 动态开启碎片整理
redis-cli CONFIG SET activedefrag yes
# 观察效果
watch -n 2 'redis-cli INFO memory | grep -E "fragmentation|used_memory_rss_human"'

# 1. 是数据涨了还是开销涨了
MEMORY STATS   # 比较 dataset.bytes 和 overhead.total 的变化

# 2. key 数量在涨？
DBSIZE
INFO keyspace     # 对比 keys 和 expires——如果 keys 涨而 expires 没涨，
                  # 说明有大量 key 没设 TTL（常见泄漏源！）

# 3. 有大 key 在涨？
redis-cli --bigkeys
# 定期记录关键 key 的大小
MEMORY USAGE somekey

# 4. 客户端缓冲区在涨？
CLIENT LIST | awk '{for(i=1;i<=NF;i++) if($i ~ /^omem=/) print $i}' | sort -t= -k2 -rn | head
INFO clients

# 5. Lua 脚本缓存在涨？（动态生成脚本的泄漏）
MEMORY STATS | grep -A1 lua.caches
SCRIPT FLUSH      # 清空（会导致客户端的 EVALSHA 收到 NOSCRIPT，但客户端会自动回退）

# 6. 复制缓冲区在涨？
INFO replication  # 看从节点的 offset 差距
CLIENT LIST TYPE replica

# 7. 是不是碎片
INFO memory | grep fragmentation

# ---------- 1. 内存过量分配（否则 fork 可能失败）----------
echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf

# ---------- 2. TCP 全连接队列（默认 128 太小）----------
echo 'net.core.somaxconn = 1024' >> /etc/sysctl.conf
# Redis 的 tcp-backlog 也要相应调大
# redis.conf: tcp-backlog 511

# ---------- 3. 关闭透明大页（COW 粒度从 4KB 变 2MB，放大 512 倍）----------
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
# 持久化（写进 rc.local 或用 tuned profile）
cat >> /etc/rc.local <<'EOF'
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
EOF

# ---------- 4. 文件描述符上限 ----------
echo '* soft nofile 65535' >> /etc/security/limits.conf
echo '* hard nofile 65535' >> /etc/security/limits.conf
# systemd 服务还要加 LimitNOFILE=65535

sysctl -p

# 启动 Redis 后看日志，如果有 WARNING 就是没配好
grep -i warning /var/log/redis/redis.log
# 常见警告：
# WARNING: The TCP backlog setting of 511 cannot be enforced because
#          /proc/sys/net/core/somaxconn is set to the lower value of 128.
# WARNING overcommit_memory is set to 0!
# WARNING you have Transparent Huge Pages (THP) support enabled

# ---------- swap ----------
# 【最好完全关闭】
swapoff -a
# 或者至少让内核极不情愿使用 swap
echo 'vm.swappiness = 1' >> /etc/sysctl.conf
# 注意：不是 0！0 在某些内核版本会触发 OOM Killer 而不是用 swap

# ---------- 脏页回写（影响 AOF 的 write 是否会阻塞）----------
echo 'vm.dirty_background_ratio = 5' >> /etc/sysctl.conf   # 后台开始回写的阈值
echo 'vm.dirty_ratio = 10' >> /etc/sysctl.conf             # 强制同步回写的阈值
# 默认值（10/20）在大内存机器上意味着可能积累几个 GB 脏页，
# 一次性回写会导致长时间的 IO 阻塞

# ---------- TCP 相关 ----------
echo 'net.ipv4.tcp_max_syn_backlog = 8192' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_tw_reuse = 1' >> /etc/sysctl.conf       # 复用 TIME_WAIT
echo 'net.ipv4.ip_local_port_range = 10000 65000' >> /etc/sysctl.conf
echo 'net.core.netdev_max_backlog = 5000' >> /etc/sysctl.conf

# ---------- NUMA ----------
# 检查是否有 NUMA
numactl --hardware
# 【不推荐】用 numactl 绑定（可能导致单节点内存不足）
# 【推荐】关闭 NUMA balancing，或在 BIOS 里关闭 NUMA
echo 0 > /proc/sys/kernel/numa_balancing

# ---------- CPU 节能模式（会造成延迟毛刺）----------
# 设为 performance
for cpu in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
  echo performance > $cpu
done

# 用 taskset 绑定到特定核心
taskset -c 0 redis-server /etc/redis/7000.conf
taskset -c 1 redis-server /etc/redis/7001.conf

# systemd 里配置
# CPUAffinity=0

# 【注意】6.0+ 有专门的配置项，比 taskset 更精细
# redis.conf:
server_cpulist 0-3          # 主线程和 IO 线程用哪些核
bio_cpulist 4,5             # bio 后台线程
aof_rewrite_cpulist 6,7     # AOF 重写子进程
bgsave_cpulist 6,7          # RDB 子进程

# 1. AOF 和 RDB 放独立磁盘（避免和其他 IO 争抢）
# redis.conf: dir /data/redis   ← 挂载独立的 SSD

# 2. 检查磁盘性能
fio --name=test --rw=randwrite --bs=4k --size=1G --numjobs=1 --direct=1 --sync=1
# fsync 延迟是关键指标（AOF everysec 依赖它）

# 3. 监控磁盘饱和度
iostat -x 1
# %util 接近 100% 说明磁盘饱和
# await 高说明 IO 排队严重

rdb := redis.NewClient(&redis.Options{
    Addr:     "127.0.0.1:6379",

    // 【连接池大小】：不是越大越好
    // 经验值：每个 CPU 核心 10 个连接，或者 QPS/1000
    // 太大会导致 Redis 端 maxclients 压力和更多的上下文切换
    PoolSize:     50,
    MinIdleConns: 10,          // 预热连接，避免突发流量时建连延迟

    // 【超时】必须设置，否则网络问题会导致 goroutine 无限堆积
    DialTimeout:  1 * time.Second,
    ReadTimeout:  500 * time.Millisecond,   // 大部分命令应该 < 1ms
    WriteTimeout: 500 * time.Millisecond,
    PoolTimeout:  1 * time.Second,          // 等待可用连接的超时

    // 连接生命周期
    ConnMaxIdleTime: 5 * time.Minute,
    ConnMaxLifetime: 0,                     // 0 = 不主动关闭

    // 重试
    MaxRetries:      2,
    MinRetryBackoff: 8 * time.Millisecond,
    MaxRetryBackoff: 512 * time.Millisecond,
})

stats := rdb.PoolStats()
log.Printf("hits=%d misses=%d timeouts=%d total=%d idle=%d stale=%d",
    stats.Hits, stats.Misses, stats.Timeouts,
    stats.TotalConns, stats.IdleConns, stats.StaleConns)
// Timeouts > 0 说明池不够用
// Misses 高说明连接经常要新建（考虑调大 MinIdleConns）

// ❌ N 次 RTT
for _, id := range ids {
    rdb.Get(ctx, key(id))
}

// ✅ 1 次 RTT：批量命令
rdb.MGet(ctx, keys...)

// ✅ 1 次 RTT：pipeline（命令类型不同时用）
pipe := rdb.Pipeline()
for _, id := range ids {
    pipe.HGetAll(ctx, key(id))
}
cmds, _ := pipe.Exec(ctx)
// 【必须遍历检查每条命令的错误】
for _, cmd := range cmds {
    if cmd.Err() != nil { /* ... */ }
}

// ✅ 需要逻辑判断时用 Lua（1 次 RTT + 原子）
script.Run(ctx, rdb, keys, args)

// 1. 【务必设置连接名】，让服务端的 CLIENT LIST 和 SLOWLOG 能定位到服务
rdb := redis.NewClient(&redis.Options{
    ClientName: "order-service-" + hostname,
})

// 2. 序列化用更快的格式
// JSON → msgpack / protobuf / sonic（更快的 JSON 库）
// 大 value 加压缩（zstd/snappy）

// 3. 本地缓存挡住热点（第 14 篇）

// 4. 只读命令走从节点（谨慎，有延迟问题，第 10 篇）

// 5. 避免在循环里做 Redis 调用（改成批量）

// 6. 监控客户端侧的 P99 延迟，和服务端的 commandstats 对比
//    两者差值大 = 网络或客户端问题

# 基本压测（默认 50 并发、10 万请求、测所有命令）
redis-benchmark -h 127.0.0.1 -p 6379 -a password

# 只测特定命令
redis-benchmark -t set,get -n 1000000 -c 100 -q
# -t 命令  -n 请求数  -c 并发连接数  -q 只输出汇总

# 测不同的 value 大小（很重要，大 value 的吞吐差别巨大）
redis-benchmark -t set -n 100000 -d 100      # 100 字节
redis-benchmark -t set -n 100000 -d 10240    # 10KB

# 测 pipeline 的效果
redis-benchmark -t set,get -n 1000000 -P 16 -q
# -P 16 = 每次 pipeline 16 个命令

# 用随机 key（避免所有请求都命中同一个 key，更接近真实场景）
redis-benchmark -t set,get -n 1000000 -r 1000000 -q
# -r 1000000 = key 在 100 万个随机值里选

# 测自定义命令
redis-benchmark -n 100000 eval "return redis.call('GET', KEYS[1])" 1 mykey
redis-benchmark -n 100000 hset myhash field:__rand_int__ value

# 集群模式
redis-benchmark --cluster -h 127.0.0.1 -p 7000

# 只保持连接不发命令（测 maxclients）
redis-benchmark -c 10000 -n 1 --keep-alive

# memtier_benchmark（Redis Labs 出品，功能更强）
memtier_benchmark -s 127.0.0.1 -p 6379 \
  --protocol=redis \
  -c 50 -t 4 \                    # 50 连接 × 4 线程
  --ratio=1:10 \                  # 写:读 = 1:10
  --data-size=100 \
  --key-pattern=R:R \             # 随机 key
  --pipeline=16 \
  --test-time=60

redis-cli SLOWLOG GET 10
# 1) 1) (integer) 152
#    2) (integer) 1785657600
#    3) (integer) 3852000        ← 3.85 秒！
#    4) 1) "KEYS"
#       2) "*"
#    5) "10.0.0.88:41234"
#    6) ""                        ← 没设置 client name，只能靠 IP 定位

# 1. 立即禁用危险命令
CONFIG SET ... # 需要改配置文件后重启，或用 ACL
rename-command KEYS ""
# 6.0+ 可以用 ACL 更灵活地控制
ACL SETUSER readonly on >pwd ~* +@read -keys -flushall -flushdb

# 2. 统计 key 数用 DBSIZE（O(1)）
DBSIZE

# 3. 遍历用 SCAN
redis-cli --scan --pattern 'user:*' | wc -l

# 4. 强制所有应用设置 CLIENT SETNAME（便于定位）

redis-cli --bigkeys
# [00.00%] Biggest hash found so far 'product:categories:all' with 1200000 fields

redis-cli MEMORY USAGE product:categories:all
# (integer) 268435456           ← 256MB！

redis-cli INFO commandstats | grep hgetall
# cmdstat_hgetall:calls=3600,usec=1080000000,usec_per_call=300000.00
#                                              ↑ 平均 300ms

grep -E 'save|appendonly' redis.conf
# save ""
# appendonly no                 ← 完全没有持久化

systemctl cat redis
# Restart=always                ← 自动重启

redis-cli INFO stats | grep -E 'sync_full|sync_partial'
# sync_full:127                 ← 一小时增长了 127 次！
# sync_partial_err:89

redis-cli CONFIG GET repl-backlog-size
# 1) "repl-backlog-size"
# 2) "1048576"                  ← 只有 1MB（默认值）

grep 'scheduled to be closed' redis.log | wc -l
# 89                            ← 从节点因输出缓冲区超限被断开

redis-cli SCRIPT KILL
# (error) UNKILLABLE Sorry the script already executed write commands
#         against the dataset. You can either wait the script termination
#         or kill the server in a hard way using the SHUTDOWN NOSAVE command.

-- 1. 循环次数必须有【硬编码的小上限】
local n = math.min(tonumber(ARGV[1]) or 0, 100)
for i = 1, n do ... end

-- 2. 【所有校验在前，所有写入在后】
--    这样至少在校验阶段还能被 SCRIPT KILL

-- 3. 上线前必须用生产规模的数据测试

redis-cli INFO keyspace
# db0:keys=8000000,expires=1200000,avg_ttl=1800000
#            ↑ 800 万 key      ↑ 但只有 120 万有 TTL！

# 抽样检查缓存 key 的 TTL
redis-cli --scan --pattern 'cache:user:*' | head -100 | while read k; do
  echo "$(redis-cli TTL "$k") $k"
done | sort -n | head
# -1 cache:user:1001            ← 没有过期时间！
# -1 cache:user:1002

// 写入时正确设置了 TTL
rdb.Set(ctx, key, val, time.Hour)

// 但更新时用了不带 TTL 的 SET —— 【TTL 被清除，key 变成永久】
func UpdateCache(ctx context.Context, key string, val []byte) {
    rdb.Set(ctx, key, val, 0)      // ← 0 表示永不过期！
}

// 方案一：更新时也带 TTL
rdb.Set(ctx, key, val, randomTTL(time.Hour))

// 方案二：用 KEEPTTL 保留原有 TTL（6.0+）
rdb.Set(ctx, key, val, redis.KeepTTL)

// 方案三：更新时干脆删除，让下次读取重建（Cache Aside，第 14 篇）
rdb.Del(ctx, key)

# 定期比对 keys 和 expires 的比例，异常时告警
redis-cli INFO keyspace

# ========== 可用性 ==========
PING 是否成功
role（主从角色是否符合预期）
master_link_status（从节点，必须是 up）
cluster_state（集群，必须是 ok）
cluster_slots_assigned（必须 16384）

# ========== 性能 ==========
instantaneous_ops_per_sec        # 实时 QPS
latency（redis-cli --latency 或客户端埋点 P99）
slowlog 条数增长
cmdstat_* 的 usec_per_call

# ========== 内存 ==========
used_memory / maxmemory          # 使用率，> 80% 告警
used_memory_rss
mem_fragmentation_ratio          # < 1 紧急（swap）；> 1.5 告警（碎片）
evicted_keys                     # 快速增长 = 内存不足
keys.bytes-per-key（MEMORY STATS）

# ========== 命中率 ==========
keyspace_hits / (keyspace_hits + keyspace_misses)   # < 90% 要排查

# ========== 连接 ==========
connected_clients                # 接近 maxclients 告警
blocked_clients                  # 阻塞客户端数
rejected_connections             # > 0 说明超过 maxclients
client_recent_max_input_buffer
client_recent_max_output_buffer  # 大 key 或慢消费者的信号

# ========== 持久化 ==========
rdb_last_bgsave_status           # 必须 ok
aof_last_bgrewrite_status        # 必须 ok
aof_last_write_status            # 必须 ok（不 ok 说明正在丢数据！）
rdb_changes_since_last_save
latest_fork_usec                 # > 100000（100ms）告警
aof_delayed_fsync                # 持续增长 = 磁盘慢

# ========== 复制 ==========
connected_slaves                 # 少于预期告警
master_repl_offset - slave_repl_offset   # 复制延迟（字节）
slaveN 的 lag                    # 复制延迟（秒）
sync_full                        # 5 分钟内增长 > 1 次告警
sync_partial_err                 # 任何增长都要关注

# ========== 过期与淘汰 ==========
expired_keys
expired_time_cap_reached_count   # 持续增长 = 过期压力大

# ========== 系统 ==========
CPU 使用率（单核，Redis 主线程）
内存使用率
网卡流量（in/out，接近带宽上限告警）
磁盘 IO（%util、await）
是否在 swap

# 1. Prometheus + redis_exporter（最主流）
docker run -d -p 9121:9121 oliver006/redis_exporter \
  --redis.addr=redis://127.0.0.1:6379 \
  --redis.password=xxx
# Grafana 导入 dashboard ID 763 或 11835

# 2. 云厂商自带监控（阿里云、腾讯云、AWS）
# 通常包含热 key/大 key 分析、慢日志采集、性能趋势

# 3. 自建采集脚本（简单场景）
redis-cli INFO all | grep -E 'used_memory:|connected_clients:|...'

# 4. 每日巡检脚本
#!/bin/bash
echo "=== 大 key 扫描 ==="
redis-cli --bigkeys 2>&1 | grep -E 'Biggest|found'
echo "=== 慢查询 Top 10 ==="
redis-cli SLOWLOG GET 10
echo "=== 内存诊断 ==="
redis-cli MEMORY DOCTOR
echo "=== 延迟诊断 ==="
redis-cli LATENCY DOCTOR
echo "=== 无 TTL 的缓存 key 抽样 ==="
redis-cli --scan --pattern 'cache:*' | head -100 | \
  while read k; do [ "$(redis-cli TTL "$k")" = "-1" ] && echo "$k"; done

redis-cli --latency                  # 服务端 + 网络的延迟
redis-cli --intrinsic-latency 100    # 【机器固有延迟】，> 1ms 说明机器本身有问题
# 客户端埋点的 P99 与服务端 commandstats 对比，差值大 = 网络或客户端问题

redis-cli LATENCY DOCTOR             # 【最直接】告诉你是哪类延迟事件
redis-cli SLOWLOG GET 100            # 慢命令
redis-cli INFO commandstats          # 哪个命令占用总时间最多
redis-cli INFO memory                # 碎片率 < 1 说明用了 swap
redis-cli INFO stats                 # latest_fork_usec、evicted_keys
redis-cli INFO persistence           # aof_delayed_fsync

redis-cli --bigkeys / --memkeys / --hotkeys

# 1. 是数据涨了还是开销涨了
MEMORY STATS    # 比较 dataset.bytes 和 overhead.total

# 2. 【最常见】有大量 key 没设 TTL
INFO keyspace   # 对比 keys 和 expires——keys 涨而 expires 没涨就是它
redis-cli --scan --pattern 'cache:*' | head -100 | \
  while read k; do [ "$(redis-cli TTL "$k")" = "-1" ] && echo "$k"; done

# 3. 有大 key
redis-cli --bigkeys / --memkeys

# 4. 客户端缓冲区
CLIENT LIST     # 看 omem
INFO clients

# 5. Lua 脚本缓存泄漏（动态生成脚本）
MEMORY STATS | grep lua.caches

# 6. 复制缓冲区
INFO replication

# 7. 碎片
INFO memory | grep fragmentation

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# 1. vm.overcommit_memory = 1
#    否则内核按最坏情况估算 fork 需要的内存，已用内存超过物理内存一半时 fork 会失败
echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf

# 2. net.core.somaxconn 调大（默认 128 太小，高并发建连会丢）
echo 'net.core.somaxconn = 1024' >> /etc/sysctl.conf

# 3. 关闭 THP（见 Q8）
echo never > /sys/kernel/mm/transparent_hugepage/enabled

# 4. 提高文件描述符上限
echo '* soft nofile 65535' >> /etc/security/limits.conf
echo '* hard nofile 65535' >> /etc/security/limits.conf

DialTimeout:  1 * time.Second
ReadTimeout:  500 * time.Millisecond   // 大部分命令应该 < 1ms
WriteTimeout: 500 * time.Millisecond
PoolTimeout:  1 * time.Second

cmdstat_get:calls=1000000,usec=1500000,usec_per_call=1.50
cmdstat_hgetall:calls=1000,usec=15000000,usec_per_call=15000.00
#                    ↑只调用1000次      ↑但总耗时15秒，平均15ms

# 按总耗时排序
redis-cli INFO commandstats | sed 's/cmdstat_//' | \
  awk -F'[:,=]' '{print $6, $2}' | sort -rn | head -10