Redis的主从复制与集群

Redis

• 持久化
• 主从复制
• 集群

持久化

Redis 的高性能核心源于其将数据主要存储在内存中（配合高效的内存管理和 IO 模型），但内存数据易失，一旦 Redis 进程异常退出、服务器重启或宕机，内存中的数据会全部丢失。为解决这一问题，Redis 提供了持久化机制：将内存中的数据同步到硬盘（磁盘），保证数据的持久性，使得 Redis 重启后能从磁盘文件中恢复数据。

Redis 支持两种核心的持久化方式：RDB（快照式）和 AOF（日志式），可以单独使用其中一种或将二者结合使用。

一、RDB 持久化

RDB（Redis Database）是 Redis 默认启用的持久化方式，核心原理是：在满足预设条件时，将 Redis 内存中的整个数据集生成二进制快照文件（默认文件名 dump.rdb），并写入磁盘。

RDB 触发方式

通过 redis.conf 配置文件中的 save 规则触发（每个条件之间是 "或" 的关系）：

save 900 1

save 300 10

save 60 10000

save 900 1 表示15分钟（900秒钟）内至少1个键被更改则进行快照，save 300 10 表示5分钟（300秒）内至少10个键被更改则进行快照，save 60 10000 表示60秒内至少10000个键被更改则进行快照。

RDB 核心配置

在 redis.conf 中 dir 用于指定 rdb 快照文件的位置

在 redis.conf 中 dbfilenam 用于指定 rdb 快照文件的名称（默认 dump.rdb）

Redis 启动时，若检测到 dump.rdb 文件存在，会自动加载该文件将数据恢复到内存。加载速度极快（二进制文件直接解析），通常 1GB 左右的快照文件（约千万级字符串键）载入耗时 20～30 秒（具体取决于服务器性能）。

但 RDB 的核心缺陷是数据安全性低：一旦 Redis 异常退出，会丢失最后一次快照完成后所有的修改操作。因此需根据业务场景合理配置 save 规则，将数据损失控制在可接受范围（若无法承受任何数据丢失，需配合 AOF 使用）。

二、AOF持久化

AOF（Append Only File）是日志式持久化方式，核心原理是：记录 Redis 所有写操作命令（如 SET、HSET、INCR 等，读操作不记录）到文本日志文件中，Redis 重启时通过重新执行日志中的命令，恢复数据。

AOF 核心配置

默认情况下 Redis 没有开启 AOF 方式的持久化，通过 appendonly 参数开启，配置项：appendonly yes

存储目录与文件名：AOF 文件的存储目录与 RDB 共用 dir 配置项，默认文件名是 appendonly.aof，可通过 appendfilename 参数修改（如 appendfilename appendonly.aof）

Redis 启动时，若同时开启 RDB 和 AOF，会优先加载 AOF 文件（数据更完整），仅 AOF 开启时，逐条执行 AOF 日志中的命令恢复数据，恢复速度慢于 RDB（文本命令需解析执行）。

AOF 日志为文本格式，可读性强，若日志中存在错误命令，可手动编辑修复后再加载。

主从复制

Redis 的主从结构是 Redis 最基础、最核心的高可用架构，核心设计思路是一主多从、主写从读、从库同步主库数据，主要解决数据备份和读写分离的问题，也是后续哨兵（Sentinel）、集群（Cluster）的基础。

持久化保证了即使redis服务重启也不会丢失数据，因为redis服务重启后会将硬盘上持久化的数据恢复到内存中，但是当redis服务器的硬盘损坏了可能会导致数据丢失，如果通过redis的主从复制机制就可以避免这种单点故障，如下图：

Redis 主从架构中只有两种节点角色，支持一主多从，也支持级联主从（从库再作为其他从库的主库），Redis5.0 后将原有的Slave（从库） 重命名为Replica（副本库）。

主库（Master）：唯一的写节点，接收所有的写操作，同时负责将自身的数据同步给所有从库；主库默认无特殊配置，开箱即可作为主库。

从库（Replica）：只读节点（默认开启只读），不能接收写操作，只能接收读操作，核心工作是同步主库的数据，保持与主库的数据一致。

主从复制不会阻塞master，在同步数据时，master 可以继续处理client 请求

主从配置

replicaof 123.56.146.124 6379

启动集群

redis 的哨兵机制

mkdir -p /usr/local/src/redis/sentinel-demo/data/{26379,26380,26381}

vi sentinel_26379.conf
cp sentinel_26379.conf sentinel_26380.conf
cp sentinel_26379.conf sentinel_26381.conf

修改各个配置文件中的数据目录和日志文件位置

../redis-5.0.4/src/redis-sentinel sentinel_26379.conf

需要先启动主哨兵，再启动各个从哨兵

../redis-5.0.4/src/redis-cli -p 26379
127.0.0.1:26379> sentinel masters

展示哨兵对主节点 mymaster（127.0.0.1:6379）的监控状态

集群

基于 Redis 5 搭建 Redis Cluster 集群，Redis 5.0 及以上版本已经弃用了依赖 Ruby 的 redis-trib.rb 工具，改用原生的 redis-cli --cluster 命令管理集群，无需配置 Ruby 环境。

在 /usr/local/src/redis 下创建集群目录和各个节点的日志与数据目录

mkdir -p ./redis-cluster/700{1..6}/{logs,data}

赋予权限，避免 Redis 启动时权限不足

chmod 777 -R ./redis-cluster

Redis Cluster 节点的核心配置是 cluster-enabled yes（开启集群模式），

下面用脚本批量生成 7001~7006 集群节点的配置文件，一次性复制到命令行中运行：

# 定义基础目录
BASE_DIR="/usr/local/src/redis/redis-cluster"
mkdir -p ${BASE_DIR}/700{1..6}/{logs,data}  

# IP获取：只取第一个非127.0.0.1的IPv4地址
IP=`ip a|grep 'inet' |grep -v '127.0.0.1'|grep -v 'inet6'|awk '{print $2}'|awk -F'/' '{print $1}'|head -n1`
for i in {1..6}
do
cat > ${BASE_DIR}/700${i}/redis.conf <<EOF
daemonize yes 
port 700${i} 
cluster-enabled yes 
cluster-config-file cluster-nodes-700${i}.conf
cluster-node-timeout 15000
appendonly yes
bind ${IP}
protected-mode no
dbfilename dump-700${i}.rdb
logfile ${BASE_DIR}/700${i}/logs/redis.log
pidfile ${BASE_DIR}/700${i}/data/redis.pid
dir ${BASE_DIR}/700${i}/data
appendfilename "appendonly-700${i}.aof"
EOF
done

进入 /usr/local/src/redis/redis-cluster 目录下启动所有节点

for i in {1..6}; do
/usr/local/src/redis/redis-5.0.4/src/redis-server ./700${i}/redis.conf
done

检查启动状态

ps -ef | grep redis-server | grep -E "700[1-6]"