Redis（一）持久化、主从复制、高可用_以下哪项不是redis高可用方案-优快云博客

本文链接：https://blog.youkuaiyun.com/xulongyu_0617/article/details/116600032

本文介绍了Redis的两种持久化方式——RDB和AOF，包括它们的使用方式、优缺点。此外，还讨论了主从复制解决单点故障问题，以及哨兵（Sentinel）系统的自动故障迁移功能，确保高可用性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Redis 持久化

redis支持2种持久化方式

RDB
能够在某个时间点对redis进行持久化，文件以序列化的方式存储，大数量时恢复速度奇快。
AOF
appendOnlyFile通过在文件末尾追加redis每一笔写操作指令来完成持久化，并且redis可以支持对AOF文件的重写(BGREWRITEAOF)，从而使得AOF文件不至于太大（简单的说就是对相同的执行指令去重）。

RDB使用方式

一，备份命令save、bgsave。

save：是一种阻塞式备份方式，当该命令执行时redis是不对外提供服务的。

bgsave：当执行该命令时redis是fork了一个子进程，有子进程完成对数据的备份工作，不会阻塞父进程对外提供服务、此同样也是AOF的工作方式。

思考一个问题：为什么是调用系统的fork方法创建子进程。

1，fork 创建子进程速度快。

2，fork创建子进程时对内存的消耗比较少。fork是基于copy-on-wirte（写时复制）机制的即在创建子进程时并不会复制父进程所有的内存空间到子进程（比如现在redis有10个G，子进程不可能直接复制10个G，这样黄花菜都凉了），而是复制了父进程的虚拟地址空间里的映射关系，当某一个进程需要变更某一个值时（如下图的redis子进程），此时才会在内存中新分配一个内存地址，并指向新的映射。

二、配置文件方式

如下图配置了3条save 规则（注意这里的save 对应的是bgsave 命令），如果想关闭RDB方式通过添加 save "" 配置。

RDB缺点：

1，时点性容易导致数据丢失量大。

2，dump.rdb文件不支持拉链，需要人工去维护。

AOF使用方式

一、在配置文件找到如下配置将appendonly no 改为 yes 即可。

二、3种磁盘刷新方式。

always每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。
everysec每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据推荐（并且也是默认）。
no从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。

三、AOF重写机制(BEREWRITEAOF)

由于AOF方式是在文件中不断追加新的写命令，那么时间长了以后就会使得该文件很大。但是有些指令是可以完全合并的，比如：set k1 aaa， set k1 bbb。。。就可以只保留最后一次的，再比如 incr k2 1 incr k2 2.这种完全可以合并成 incr k2 3。

四、AOF、RDB混合使用（推荐方式）。

配置yes表示开启混合使用

开启混合使用此时如果触发了AOF重写，得到的appendonly.aof文件如下图所示，前半段是rdb全量数据，后半段是指令集。这样做的好处是在恢复时即利用了rdb导入快又利用了aof丢失记录少的特性。

AOF重写的自动触发配置项如下图

AOF重写的自动触发配置项

由单点引发的问题：

单点故障
容量问题
访问压力

主从复制

虽然redis可以支持本地持久化，来防止异常数据丢失，但是如果连redis服务器整个机器坏了，被炸了，此时服务的可靠性只靠本地持久化是不能胜任的。为了能解决上述问题，根据AKF原则可以将redis做以下扩展：

由上图可知首先我们对redis做X轴上的扩展即redis的主从复制模型。

一变多引发的数据一致性问题：

强一致性：任何时刻从任意一个节点获取的数据是相同的。如果redis要实现这种级别的一致性需要在节点之间同步阻塞来进行数据同步如下图所示，如果2个节点之前同步需要花费半个小时，此时对客户的响应时间也会变成半个小时，破坏了系统的可用性。

最终一致性：最终一致性是分布式系统中采用的最多的一种一致性解决方案是弱一致性的一种实现，也是redis默认采用的数据一致性方案如下图所示，由下图可见redis并未在master和slave之间引入第三方比如kafka，应该是为了减少系统集成尽量保证系统性能。

redis主从复制配置

哨兵（Sentinel）

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance），该系统执行以下三个任务：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

配置哨兵

redis源码目录下有一个sentinel.conf配置文件主要的配置项都在这里面可以参考配置。本例中我在/etc/redis/目录下创建了一个26379.conf哨兵配置文件

port 26379
sentinel monitor mymaster 127.0.0.1 6379 2
daemonize yes
pidfile "/var/run/redis-sentinel_26379.pid"
logfile "/var/log/redis-sentinel_26379.log"

启动命令：redis-sentinel /etc/redis/26379.conf

上述红色部分最后一个参数是权重（达成一致的哨兵数量）

哨兵选举机制

由上图(图8)可以看到，哨兵的监控都是怼到master上的，通过主可以知道有几个从，同时因为要选举所以哨兵之间也是互连的，实现方式是通过redis的发布订阅功能。故障转移这一块后面准备单独详细写一篇。

replicaof <masterip> <masterport>	Master ip地址和端口号
masterauth <master-password>	Master 密码
masteruser <username>	Master 用户名
replica-serve-stale-data	数据同步期间Slave是否对外提供服务配置项：yes(默认)/no
replica-read-only yes	Slave 只读模式配置项：yes(默认)/no
repl-diskless-sync	同步文件是否不经过磁盘直接网络I/O传输配置项：yes/no(默认)
repl-diskless-sync-delay 5	repl-diskless-sync 的配套选项默认不配置
repl-diskless-load disabled	repl-diskless-sync 的配套选项默认不配置
repl-backlog-size	增量配置配置项：mb 增量配置原理：在redis内部维护了一个位置队列，如果该队列满了会触发全量同步。