Redis主从同步与对象模型

小聂哩

482人浏览 · 2026-04-02 12:50:24

小聂哩 · 2026-04-02 12:50:24 发布

Redis主从同步与对象模型

文章目录

Redis主从同步与对象模型

Redis 作为一款内存数据库，数据全部存储在内存中。一旦发生宕机，若未做持久化，所有数据将丢失。因此， 持久化是保障 Redis 数据安全的核心机制。当 Redis 重启时，可通过加载持久化文件来恢复数据。

一、Redis 持久化机制

1.1 持久化配置概览

###### AOF 配置 ######
appendonly no
appendfilename "appendonly.aof"
# appendfsync always
appendfsync everysec
# appendfsync no

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# yes：若 AOF 文件不完整，尽量读取可解析部分
# no ：若 AOF 文件不完整，启动时报错，可通过 redis-check-aof 修复
aof-load-truncated yes

# 开启混合持久化（RDB + AOF）
aof-use-rdb-preamble yes

###### RDB 配置 ######
# save ""
# save 3600 1
# save 300 100
# save 60 10000

1.2 AOF（Append Only File）

AOF 以日志形式记录 Redis 接收到的所有写操作命令，并以文本协议格式追加保存。
开启方式：

appendonly yes
auto-aof-rewrite-percentage 0   # 关闭重写
aof-use-rdb-preamble no          # 关闭混合持久化
# save ""                        # 关闭 RDB

优点：

数据安全性高，最多丢失一秒内的数据（everysec 策略）。

缺点：

日志文件随时间持续增长，重启时重放所有命令导致恢复缓慢；
包含大量冗余或可合并的命令。

AOF 重写（Rewrite）

为解决 AOF 文件膨胀问题，Redis 支持 AOF 重写机制：

当 AOF 文件满足一定条件（如文件大小超过上次重写后大小的 100%，且 ≥ 64MB）时，Redis 会 fork 一个子进程；
子进程根据当前内存中的数据，生成最小化的命令集，写入新的 AOF 文件；
重写期间新的写操作会记录到旧 AOF 文件及内存缓冲区；
新文件写完后，Redis 将缓冲区的增量命令追加到新文件末尾，最后原子替换旧文件。

配置示例：

appendonly yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-use-rdb-preamble no
save ""

1.3 RDB（Redis Database）

RDB 是一种快照持久化方式。Redis 会 fork 一个子进程，将当前内存中的数据以二进制压缩形式写入 .rdb 文件。

配置示例：

appendonly no
auto-aof-rewrite-percentage 0
aof-use-rdb-preamble no
save 3600 1
save 300 100
save 60 10000

优点：

文件体积小，恢复速度快；
适合备份和灾难恢复。

缺点：

若 Redis 意外宕机，最后一次快照之后的数据将丢失；
当数据集较大时，fork 操作可能造成毫秒到秒级的服务阻塞（尤其在 CPU 资源紧张时）。

1.4 混合持久化

混合持久化结合 RDB 与 AOF 的优点：

在 AOF 重写时，子进程先将当前内存数据以 RDB 格式写入新 AOF 文件头部；
重写期间的新增写操作以 AOF 格式追加到文件尾部。
重启时先加载 RDB 部分，再执行 AOF 增量命令，兼顾快速恢复与数据安全。

配置示例：

appendonly yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-use-rdb-preamble yes
save ""

持久化的优缺点分析：

有aof，rdb，aof-rewrite，aof-rdb混用四种。

持久化方式	优点	缺点
RDB	文件体积小，恢复速度快；适合定时备份与灾难恢复。	宕机可能丢失最后一次快照后的数据；数据集大时 fork 子进程可能短暂阻塞服务。
AOF	数据安全性高（`everysec` 最多丢 1 秒数据）；日志可读，便于误操作恢复。	文件体积大，重启恢复慢；频繁写入可能影响性能。
AOF 重写（Rewrite）	可有效压缩 AOF 文件体积，去除冗余命令，减少恢复时间。	重写期间仍会占用额外内存和磁盘 I/O；fork 子进程同样有短暂阻塞风险。
混合持久化（RDB + AOF）	重启时先加载 RDB 头部，再回放少量 AOF 增量，兼具快速恢复与数据安全。	文件格式复杂，低版本 Redis 可能不兼容；重写时仍需 fork 子进程。

说明：

AOF 重写是 AOF 的一种维护机制，并非独立持久化类型，但实际配置和运行时需要单独考量其优缺点。
混合持久化需 Redis 4.0+ 并开启 aof-use-rdb-preamble yes。

1.5 写时复制（Copy-on-Write）

Redis 在生成 RDB 或 AOF 重写时，父进程会 fork 一个子进程。

父子进程共享同一份物理内存页表，页表被标记为只读；
当父进程收到新的写请求时，触发写保护中断，复制一个新的内存页并且改为可读可写状态；
子进程则继续使用原有内存页完成持久化任务。
这种机制使得持久化过程对服务影响降到最低。

请添加图片描述

二、Redis 内存淘汰策略

当 Redis 内存使用达到 maxmemory 限制时，根据 maxmemory-policy 进行淘汰。
maxmemory 通常建议设置为系统可用内存的一半左右，避免与操作系统、其他进程争抢内存，同时防止频繁触发 swap 或 OOM（Out Of Memory）。

支持的淘汰策略：

策略	说明
`noeviction`	默认策略，内存不足时写入操作返回错误
`volatile-lru`	从设置了过期时间的 key 中淘汰最近最少使用的
`allkeys-lru`	从所有 key 中淘汰最近最少使用的
`volatile-lfu`	从设置了过期时间的 key 中淘汰最不经常使用的
`allkeys-lfu`	从所有 key 中淘汰最不经常使用的
`volatile-random`	从设置了过期时间的 key 中随机淘汰
`allkeys-random`	从所有 key 中随机淘汰
`volatile-ttl`	从设置了过期时间的 key 中淘汰 TTL 最小的

LRU（Least Recently Used）与 LFU（Least Frequently Used）分别基于访问时间与访问频率进行淘汰，LFU 能更好应对长期热点与短期突发访问的区分。

三、Redis 主从复制

主从复制是 Redis 实现数据冗余与高可用的基础。主节点负责处理写请求，并将数据变更异步复制给一个或多个从节点。

3.1 配置方式

# 启动时指定主节点
redis-server --replicaof 127.0.0.1 7001

# 或在配置文件中配置（Redis 5.0 前使用 slaveof）
replicaof 127.0.0.1 7002

查看复制状态：

redis-cli info replication

3.2 数据同步流程

3.2.1全量同步

从节点首次连接或复制偏移量落后过多时触发；
主节点执行 bgsave 生成 RDB 文件，并发送给从节点；
从节点清空自身数据，加载 RDB；
主节点将同步期间缓存的写命令（replication buffer）发送给从节点，完成追赶。

3.2.2增量同步

主从连接断开后重连，若复制偏移量仍在复制积压缓冲区（repl-backlog-buffer）范围内，主节点仅发送缺失的命令；
通过 PSYNC 命令实现断点续传，减少网络开销。

四、Redis 哨兵模式（Sentinel）

哨兵模式是 Redis 官方提供的高可用解决方案。一个或多个 Sentinel 实例组成分布式监控系统，可监控主从架构并自动执行故障转移。

请添加图片描述

4.1 核心功能

监控：定期检查主从节点健康状态；
通知：通过 API 向管理员或其他程序发送告警；
自动故障转移：当主节点不可用时，选举一个从节点升级为新主节点，并修改其他从节点的复制目标；
配置提供：客户端连接时，先从 Sentinel 获取当前主节点地址。

4.2 故障转移流程

主观下线：Sentinel 实例通过 ping 检测到主节点无响应；
客观下线：多个 Sentinel 实例对主节点下线达成共识（通过 quorum 配置）；
领导者选举：基于 Raft 算法从 Sentinel 集群中选举一个 Leader；
故障转移：Leader 选择最优从节点（优先级、复制偏移量、运行 ID 等）升级为主节点，并通知其他从节点复制新主节点。

五、Redis Cluster 集群

Redis Cluster 是 Redis 官方提供的分布式解决方案，支持数据自动分片与高可用。

5.1 核心设计

槽位（Slot）：将数据划分为 16384 个哈希槽，每个 key 通过 CRC16(key) % 16384 确定所属槽位；
节点分工：每个节点负责一部分槽位，多个节点共同组成完整数据空间；
去中心化：节点间通过 Gossip 协议交换状态信息，无需中心化组件；
客户端直接访问：客户端缓存槽位与节点的映射关系，可直连目标节点，性能高。

5.2 集群搭建示例

5.2.1创建目录与配置

mkdir -p 700{1,2,3,4,5,6}
cd 7001
vi 7001.conf

7001/7001.conf 示例：

pidfile "/home/xiaonie_server_4/code/4.1-redis/redis-cluster/7001/7001.pid"
logfile "/home/xiaonie_server_4/code/4.1-redis/redis-cluster/7001/7001.log"
dir /home/xiaonie_server_4/code/4.1-redis/redis-cluster/7001
port 7001
daemonize yes
cluster-enabled yes
cluster-config-file nodes-7001.conf
cluster-node-timeout 15000

复制并修改其他节点配置：

for port in 7002 7003 7004 7005 7006; do
  cp 7001/7001.conf $port/$port.conf
  sed -i "s/7001/$port/g" $port/$port.conf
done

5.2.2启动所有节点

#!/bin/bash
for port in 7001 7002 7003 7004 7005 7006; do
  /usr/local/redis/bin/redis-server $port/$port.conf
done

5.2.3创建集群

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

--cluster-replicas 1 表示为每个主节点分配一个从节点。

请添加图片描述

5.2.4测试集群

// 进入到7001
/usr/local/redis/bin/redis-cli -c -p 7001
127.0.0.1:7001> set name xiaonie
// 落到7002
//-> Redirected to slot [5798] located at 127.0.0.1:7002
//OK

//从7004进去，也可以得到name
/usr/local/redis/bin/redis-cli -c -p 7004
127.0.0.1:7004> get name
//-> Redirected to slot [5798] located at 127.0.0.1:7002
//"xiaonie"
//127.0.0.1:7002>

请添加图片描述

5.3 集群访问与故障处理

MOVED 重定向：当客户端访问的节点不负责对应槽位时，返回 -MOVED 错误，客户端需更新本地缓存并重试；
ASK 重定向：槽位迁移过程中，临时指引客户端访问目标节点；
故障转移：主节点宕机后，其从节点通过选举成为新主节点，集群继续可用。

5.4 hiredis-cluster 客户端编译（C/C++ 示例）

git clone https://github.com/Nordix/hiredis-cluster.git
cd hiredis-cluster
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_SSL=ON ..
make
sudo make install
sudo ldconfig

6. 总结

特性	说明
RDB	快照方式，适合备份与快速恢复，可能丢失少量数据
AOF	日志方式，数据安全性高，但文件体积大，恢复慢
混合持久化	RDB + AOF 互补，兼顾恢复速度与数据安全
主从复制	数据冗余基础，异步复制，支持读写分离
哨兵模式	自动化故障转移，保障服务高可用
Cluster 集群	水平扩展 + 高可用，数据分片，去中心化