Redis03:持久化存储，大key分析，主从复制及哨兵模式

9.redis的两种持久化方式存储

RDB 持久化（快照）

把某一时刻全量内存数据，以二进制快照保存到dump.rdb文件。

默认配置

存储路径：dir 参数，示例/data/redis

文件名：dbfilename dump.rdb

自动触发规则（save配置）

save 3600 1   # 1小时，至少1个key变化
save 300 100  # 5分钟，至少100个key变化
save 60 10000 # 1分钟，至少10000个key变化

key 变化越频繁，快照触发越频繁；关闭 Redis 服务也会立刻生成 RDB 快照。

关闭 RDB 持久化

命令行临时关闭：

config set save ""
config rewrite   #写入配置文件永久生效

修改配置文件/etc/redis.conf

save ""
# save 3600 1
# save 300 100
# save 60 10000

⚠️注意：关闭前要手动删除旧的dump.rdb，否则重启依旧会加载旧快照恢复数据。关闭 RDB 后，重启 Redis 内存数据全部丢失。

rdbcompression no：关闭 rdb 文件压缩，磁盘空间充足时使用。

RDB 优缺点

✅优点：文件小、恢复速度快，适合全量备份

❌缺点：是快照，两次快照之间的数据会丢失；大数据量生成快照会消耗 CPU。

AOF 持久化（追加日志）

记录每一条写命令，追加写入appendonly.aof，类似 MySQL binlog；默认关闭。

同时开启 RDB+AOF 时，Redis 优先加载 AOF 文件恢复数据。

开启 AOF

建议先关闭 RDB（save ""）

redis 命令：

config set appendonly yes
config rewrite

配置文件参数：

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec  #每秒刷盘（默认）

• appendfsync三种模式：
  • always：每写一条命令立刻刷盘，最安全性能差
  • everysec：每秒刷盘，折中方案（默认）
  • no：交给操作系统决定刷盘，性能高，丢失风险大

AOF 重写（解决文件无限膨胀）

反复执行相同写命令，AOF 文件会持续变大；AOF 重写会合并命令，生成精简新 aof 文件，不丢失实际数据。

手动重写

BGREWRITEAOF

自动重写触发条件（默认）

auto‑aof‑rewrite‑min‑size 67108864  # 文件大于67M
auto‑aof‑rewrite‑percentage 100     # 文件比上次重写后增大100%(翻倍)

⚠️业务高峰期自动重写会消耗 CPU，影响业务；可以在业务低峰期脚本手动执行BGREWRITEAOF。

AOF 优缺点

✅优点：数据安全性更高，丢失数据最多 1 秒（everysec）

❌缺点：AOF 文件体积更大；故障恢复速度比 RDB 慢。

RDB vs AOF 对比表

对比项	RDB	AOF
默认状态	开启	关闭
存储内容	某时间点全量二进制快照	每条写操作命令日志
文件	dump.rdb	appendonly.aof
恢复速度	快	慢
数据丢失风险	两次快照间全部数据丢失	everysec 模式最多丢 1 秒数据
文件大小	小	大，需要重写压缩

生产建议：

1. 追求性能、允许少量数据丢失：使用 RDB
2. 追求高数据安全：使用 AOF
3. Redis4.0 以后支持混合持久化：AOF 重写时开头写入 RDB 快照，兼顾两者优势。

常用操作命令汇总

#RDB相关
config get dir                     #查看rdb保存目录
config get dbfilename              #查看rdb文件名
config get save                    #查看RDB快照策略
config set save ""                 #关闭RDB

#AOF相关
config get append*                 #查看全部AOF配置
config set appendonly yes          #开启AOF
BGREWRITEAOF                       #手动AOF重写
config get aof*                    #查看AOF自动重写参数
config rewrite                     #把内存配置写入redis.conf永久生效

系统层面操作

#删除旧rdb文件
rm -f /data/redis/dump.rdb
#查看aof文件内容
tail -12 /data/redis/appendonly.aof
#压测工具制造大量写入，触发AOF自动重写
redis‑benchmark -a redis pwd

.

10. redis的RDB工具分析key的大小

BigKey：Redis 中 value 值很大的 key，序列化、反序列化耗时高，容易阻塞 Redis、占用大流量、消耗大量内存。

判断标准（经验阈值）

• String 字符串：value 长度＞10K 判定为大 key
• List 列表：元素数量＞1024 判定为大 key

风险：操作大 key 容易阻塞 Redis 主线程，引发性能抖动。

扫描 & 分析 BigKey 两种方法

方法 1：redis-cli --bigkeys（在线采样分析，直接连接 redis）

redis-cli -a redispwd --bigkeys

• 原理：采样部分 key 统计，不是全量扫描；输出每种数据类型最大的 key、元素 / 字节大小
• 输出示例：
• 

⚠️缺点：是采样，会有遗漏；线上执行会有少量性能消耗。

方法 2：rdbtools 工具，解析 dump.rdb 文件（离线分析，推荐生产）

建议把 rdb 拷贝到闲置服务器分析，不要在业务实例执行

环境依赖 python3

yum -y install python36
pip3 install rdbtools==0.1.15 -i https://mirrors.aliyun.com/pypi/simple/

解析 rdb 导出 csv 文件

rdb -c memory dump.rdb > /tmp/test.csv

查看输出文件

cat /tmp/test.csv |head -5

按内存大小降序排序，找最大 key

cat /tmp/test.csv |sort -nrk 4 -t ',' |head -5

删除 BigKey & 验证

直接删除大 key

DEL k1

再用 bigkeys 工具校验，该大 key 不再出现在统计结果：

redis-cli -a 123456 --bigkeys

⚠️补充知识点（拓展）： 如果是超大 bigkey，直接DEL会阻塞主线程；生产环境不能直接 DEL。

• String：可以分批 unlink 删除；
• List/Hash/Set/ZSet：循环分批删除元素，清空后再删除 key； Redis4.0 + 推荐使用UNLINK，异步释放内存，避免阻塞。

.

11.redis的主从复制

Redis 单台服务器的缺点

1. 持久化情况下，依然存在数据丢失风险
2. 所有读写压力全部集中在一台实例上，性能存在瓶颈

Redis 主从复制概念

• 主从复制实现多台 Redis 之间数据保持一致
• 主服务器 (master)：负责写、读操作
• 从服务器 (slave)：只做读操作，不接收写请求
• 作用：实现读写分离，分担读压力，降低主库压力

💡注意：Redis 主从复制，默认主从不会自动故障转移，主节点挂掉，从节点不会自动升级为主节点。

Redis 主从搭建

查看主从复制状态

info replication

主 Redis 配置 /etc/redis.conf

bind 0.0.0.0
port 6379
dir "/data/redis"
requirepass "redispwd"
pidfile "redis.pid"
logfile "redis.log"
daemonize yes

从 Redis 配置 /etc/redis.conf

基础配置和主库基本一致，额外增加两条主从复制配置

bind 0.0.0.0
port 6379
dir "/data/redis"
requirepass "redispwd"   # 从库自身密码，一般和主库相同
pidfile "redis.pid"
logfile "redis.log"
daemonize yes

# 新增主从复制配置
slaveof 192.168.74.11 6379   # 指定主库IP和端口
masterauth "123456"          # 指定主库的访问密码

⚠️Redis5.0 之后推荐使用 replicaof 替代 slaveof，slaveof属于旧版本写法，仍兼容。

补充拓展知识点

• 复制流程：从库启动后，向主库发起同步；主库执行 RDB 持久化，把 RDB 文件发给从库，从库加载 RDB，之后持续同步主库新产生的写命令。
• 读写分离使用方式：业务写请求全部打向 master，读请求分发到各个 slave。
• 缺陷 ：主从模式没有自动选主能力；主节点宕机，需要人工干预，这就需要哨兵 Sentinel实现自动故障转移。
• 从节点默认只读，直接在从库执行写命令会报错，保护数据一致性。

.

12. redis的哨兵实现主从自动切换

哨兵 Sentinel 作用

原生主从复制缺陷：主库宕机，不会自动切换主库，业务写请求直接报错。

Sentinel（哨兵）能力：

1. 监控：持续监控 master、slave 节点健康状态
2. 主观下线、客观下线：多个哨兵协商判断主库真的挂掉
3. 自动故障转移 failover ：挑选一台健康从库升级为新 master；其余从库跟随新主；旧主恢复后自动变成从库
4. 配置自动改写 ：哨兵会自动修改所有 redis 实例配置，更新replicaof指向新主节点

完整搭建步骤

步骤 1：先搭建好 1 主 2 从主从复制

重点：所有 Redis 节点（包括原来的 master）都配置masterauth "123456"

# /etc/redis.conf
masterauth "123456"

原因：故障切换后，旧主重启会变成从库，它需要密码去连接新的主库，避免认证失败。

步骤 2：配置 sentinel.conf（三台哨兵配置完全一样）

# /etc/sentinel.conf
bind 0.0.0.0
daemonize yes
port 26379                # 哨兵默认端口26379
dir "/tmp"
logfile "sentinel.log"

# 监控主库，testmaster是自定义集群名；2代表：至少2个哨兵认为主库故障，才判定客观下线
sentinel monitor testmaster 192.168.74.11 6379 2
sentinel auth-pass testmaster redispwd        # 访问redis的密码
sentinel down-after-milliseconds testmaster 5000   # 5000ms(5s)无响应判定主观下线
sentinel failover-timeout testmaster 18000         # 故障转移超时18000ms(18s)

参数解释：

• sentinel monitor <集群名> <主IP> <端口> <quorum>：quorum=2，仲裁数。
• down‑after‑milliseconds：哨兵多久 ping 不通就认为节点主观下线。
• failover‑timeout：一次故障转移操作最大超时时间。

步骤 3：启动三台哨兵

redis-sentinel /etc/sentinel.conf
# 查看进程
ps -ef | grep sentinel

⚠️哨兵启动后，会自动改写 sentinel.conf 配置文件，写入新的主从信息、其他哨兵节点信息，不要手动编辑运行中的 sentinel 配置。

故障模拟验证

停止原主 redis 模拟宕机

systemctl stop redis

观察哨兵日志，哨兵开始执行故障转移，把其中一台从库提升为新 master。

在升级后的节点执行info replication，看到role:master。

把原来宕机的主库重新启动：

systemctl start redis

原主库启动之后，哨兵会自动修改它的 redis.conf，追加replicaof 新主IP 6379，旧主自动降级成为新主的从库。

# 原主库配置文件会被哨兵自动修改，示例：
masterauth "123456"
replicaof 192.168.74.132 6379

哨兵高可用验证：kill 掉其中一个哨兵进程，剩余 2 个哨兵依然可以完成监控、故障转移。