redis持久化储存（RDB、AOF）和主从复制

---

redis其他笔记链接：
redis简介及八种数据类型
redis事务、乐观锁和悲观锁以及秒杀测试案例
redis持久化储存（RDB、AOF）和主从复制
redis缓存穿透、击穿、雪崩及解决方案&&分布式锁
参考学习视频链接

一、持久化储存

RDB

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文 件整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方 式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件 中,默认的文件名为dump.rdb

触发方式

save触发方式

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。

bgsave触发方式

执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求

自动触发

在redis.conf配置文件中修改，这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据 集存在n次修改时，自动触发bgsave

优势与劣势

优势：
（1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。

（2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

劣势：
RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会 拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

AOF

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读 取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF默认不开启，可以在redis.conf中配置文件名称，默认为 appendonly.aof 修改默认的appendonly no，改为yes

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

频率设置

appendfsync always 始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no redis不主动进行同步，把同步时机交给操作系统

优势与劣势

优势

• 备份机制更稳健，丢失数据概率更低。
• 可读的日志文本，通过操作AOF稳健，可以处理误操作。

劣势

• 比起RDB占用更多的磁盘空间。
• 恢复备份速度要慢。
• 每次读写都同步的话，有一定的性能压力。
• 存在个别Bug，造成恢复不能。

二、主从复制

概念

Master主机: 读写操作，只允许一个

Slave主机: 只读不能写，可以多个

准备工作

关闭安全模式: redis.conf中的protected-mode改为 fasle,否则不能进行主从复制

新建redis6379.conf,并引用redis.conf的配置

复制多份redis6379.conf，分别命名为redis6379.conf, redis6380.conf, redis6381.conf, 修改相应的配置

其中redis6379.conf作为主机，其他作为从机，分别使用多个终端启动三个redis服务

使用 info replication 命令查看信息，三个redis的role均为 master 主机

在两个从机的redis-cli中输入 slaveof 命令作为主机的从机

两个从机的 info replication 命令显示role为 slave, 并可显示主机状态和信息，主机也可查看从机的状态和信息。

薪火相传

一个从机下面可以连接多个从机,当父从机挂掉之后，后面的子从机也会挂掉

反客为主

对一个从属服务器执行命令 SLAVEOF NO ONE 将使得这个从属服务器关闭复制功能，并从从属服务器转变回主服务器，原来同步所得的数据集不会被丢弃。

如果主服务器down机，对一个从服务器运行 SLAVEOF NO ONE命令会升级为主机，该服务器下的从机继续正常运行。

哨兵模式

哨兵可以直接在主服务器down时，选择出一个从服务器，将他们作为新的主服务器，其余的从服务器跟随新的主服务器。

down掉的旧主重新启动会变成新主的从服务器

设置哨兵

创建一个sentinel.conf并写入以下内容

sentinel monitor < master-name > < ip > < port > < count >

监控的主节点的名字、IP和端口，最后一个count的意思是有几台 Sentinel 发现有问题，就会发生故障转移，例如 配置为2，代表至少有2个 Sentinel 节点认为主节点不可达，那么这个不可达的判定才是客观的。对于设置的越小，那么达到下线的条件越宽松，反之越严格。一般建议将其设置为 Sentinel 节点的一半加1

例如: sentinel monitor mymaster 127.0.0.1 6379 1

使用命令 **redis-sentinel /myredis/sentinel.conf ** 启动哨兵

哨兵服务

当主机down掉之后 ，根据从机的slave-priority大小选出新的主机，值越小优先级越高。

down掉的旧主重新启动会变成新主的从服务器

集群

Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。

Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

搭建

准备6个redis，分别为redis7001.conf,redis7002.conf, redis7003.conf redis7011.conf, redis7012.conf, redis7013.conf

三个作为主服务器，三个作为从服务器

配置文件中写入 (每个配置文件改为对应端口号)

include /myRedis/redis.conf
port 70**
pidfile "/var/run/redis_70**.pid"
dbfilename "dump70**.rdb"
logfile "/myRedis/cluster/log/redis_err_70**.log"
cluster-enabled yes
cluster-config-file nodes-70**.conf
cluster-node-timeout 15000
12345678
1
2
3
4
5
6
7
8
9

启动redis服务确定没有问题能正常启动， node-70**.conf 能正常生成。

进入redis命令目录 cd /opt/redis-6.2.6/src

使用命令启动集群服务

使用命令启动集群服务

redis-cli --cluster create --cluster-replicas 1 192.168.135.100:7001 192.168.135.100:7002 192.168.135.100:7003 192.168.135.100:7011 192.168.135.100:7012 192.168.135.100:7013

--replicas 1 表示主从复制比例为 1:1，即一个主节点对应一个从节点；然后，默认给我们分配好了每个主节点和对应从节点服务，以及 solt 的大小，因为在 Redis 集群中有且仅有 16383 个 solt ，默认情况会给我们平均分配，当然你可以指定，后续的增减节点也可以重新分配
123
1
2
3
4

输入yes确认集群的自动分配, 集群启动成功。

每一个服务器都有一个id,可能根据id查看主从关系。

每一个主节点都会分配插槽值范围，总共有1638321， redis会平均插槽给每个主节点。每次想集群中加入数据时会根据key的hash值来决定插槽大小进而决定放在哪个节点中储存。

命令

输入 redis-cli -c - p 以集群方式连接

cluster nodes 可以查看集群节点信息

cluster getkeysinslot 返回 count 个 slot中的键

cluster keyslot 返回key对应的插槽值

cluster countkeysinslot 返回插槽中key的个数

故障恢复

当主节点down后，从节点会自动变为master成为主机。down掉的主机恢复后会变成从机。

如果某一段的插槽对应的节点全部down掉， redis服务会根据以下条件决定。

redis.conf中的cluster-require-full-coverage为yes时,整个集群挂掉，

为no时，该插槽数据全都不能使用，也无法存储。

优点

实现扩容

分摊压力

无中心配置相对简单