Redis持久化，主从同步

一.Redis持久化

1.RDB快照

在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时，自动保存一次数据集。还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件， 每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。

2.bgsave的写时复制(COW)机制

Redis 借助操作系统提供的写时复制技术，在生成快照的同时，依然可以正常处理写命令。简单来说，bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。 bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作，那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据，那 么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

3.save和bgsave对比

命令	save	bgsave
IO类型	同步	异步
是否阻塞其他redis命令	是	否(在生成子进程执行调用fork函 数时会有短暂阻塞)
复杂度	O(n)	O(n)
优点	不会消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork子进程，消耗内存

4.AOF

快照功能并不是非常耐久： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失 最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方 式： AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间 fsync到磁盘)。

比如执行“set tuling 888 ex 1000”，对应aof文件里记录如下

1 *3   #星号后面的数字代表命令有多少个参数
2 $3   $号后面的数字代表这个参数有几
个字符
3 set
4 $6
5 tuling
6 $3
7 888
8 *3
9 $9
10 PEXPIREAT
11 $6
12 tuling
13 $13
14 1604249786301   #记录key过期的时间戳

你可以通过修改配置文件来打开 AOF 功能：appendonly yes

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。

1 appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。

2 appendfsync everysec（默认）：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。

3 appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。

AOF重写：AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件

如下两个配置可以控制AOF自动重写频率。

1 # auto‐aof‐rewrite‐min‐size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就 很快，重写的意义不大

2 # auto‐aof‐rewrite‐percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写

当然AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF 注意，AOF重写redis会fork出一个子进程去做(与bgsave命令类似)，不会对redis正常命令处理有太多影响。

RDB 和 AOF ，我应该用哪一个？

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	容易丢数据	根据策略决定

生产环境可以都启用，redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof 一般来说数据更全一点。

5.Redis 4.0 混合持久化

重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重 放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很 长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。 通过如下配置可以开启混合持久化(必须先开启aof)：

# aof‐use‐rdb‐preamble yes

如果开启混合持久化，AOF重写时，不再单纯将内存数据转化成RESP命令写入aof文件，而是将这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改 名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。于是在Redis重启的时候，可以先加载RDB的内容，然后再重放增量AOF日志就可以完全替代之前的 AOF全量文件重放，因此重启效率大幅得到提升。

 Redis数据备份策略：

1. 写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48 小时的备份；

2. 每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份；

3. 每次copy备份的时候，都把太旧的备份给删了；

4. 每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏；

二.Redis主从同步

Redis主从工作原理 如果你为master配置了一个slave，不管这个slave是否是第一次连接上Master，它都会发送一个PSYNC命令给master请求复制数据。

 PSYNC命令具有完整重同步和部分重同步两种模式。

完整重同步：

1.同步

1.1:从服务器向主服务器发送PSYNC命令。

1.2:收到PSYNC命令的主服务器执行BGSAVE命令,在后台生成一个RDB文件,并使用一个缓冲区记录从现在开始执行的所有写命令。

1.3:当主服务器的BGSAVE命令执行完毕时,主服务器会将BGSAVE命令生成的RDB文件发送给从服务器,从服务器接收并载人这个RDB文件,将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态。

1.4:主服务器将记录在缓冲区里面的所有写命令发送给从服务器,从服务器执行这些写命令,将自己的数据库状态更新至主服务器数据库当前所处的状态。

2. 命令传播

在同步操作执行完毕之后，主从服务器两者的数据库将达到一致状态，但这种一致并不是一层不变的，每当主服务器执行客服端发送的写命令时，主服务器的数据库就有可能会被修改，并导致主从服务器状态不再一致。为了让主从服务器再次回到一致状态,主服务器需要对从服务器执行命令传播操作：主服务器会将自己执行的写命令,也即是造成主从服务器不一致的那条写命令,发送给从服务器执,行,当从服务器执行了相同的写命令之后,主从服务器将再次回到一致状态。

部分重同步的实现

部分重同步功能由以下三个部分构成：

• 主服务器的复制偏移量和从服务器的复制偏移量。
• 主服务器的复制积压缓冲区。
• 服务器的运行ID。

1.复制偏移量

执行复制的双方——主服务器和从服务器会分别维护一个复制偏移量：主服务器每次向从服务器传播N个字节的数据时,就将自己的复制偏移量的值加上N；从服务器每次收到主服务器传播来的N个字节的数据时,就将自己的复制偏移量的值加上N。

比如主服务器和从服务器（A，B，C）的复制偏移量的值都为10000。如果这时主服务器向三个从服务器传播长度为50字节的数据，那么主服务器的复制偏移量将更新为10000+50=10050，而三个从服务器在接收到主服务器传播的数据之后,也会将复制偏移量更新为10050。通过对比主从服务器的复制偏移量，程序可以很容易地知道主从服务器是否处于一致状态。

假设主服务器要向从服务器传播长度为50字节的数据之前，从服务器A断线了，从服务器A在断线之后就立即重新连接主服务器，并且成功,那么接下来，从服务器将向主服务器发送PSYNC命令，报告从服务器A当前的复制偏移量为10000，那么这时，主服务器应该对从服务器执行完整重同步还是部分重同步呢？如果执行部分重同步的话，主服务器又如何补偿从服务器A在断线期间丢失的那部分数据呢？以上问题的答案都和复制积压缓冲区有关。

2.复制积压缓冲区

复制积压缓冲区是由主服务器维护的一个固定长度先进先出队列,默认大小为1MB。当主服务器进行命令传播时,它不仅会将写命令发送给所有从服务器 还会将写命令人 队到复制积压缓冲区里面 。

因此,主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令,并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量 。

当从服务器重新连上主服务器时,从服务器会通过PSYNC命令将自己的复制偏移量offset发送给主服务器,主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作：

• 如果offset偏移量之后的数据仍然存在于复制积压缓冲区里面、那么主服务器将对从服务器执行部分重同步操作。
• 相反,如果offset偏移量之后的数据已经不存在于复制积压缓冲区,那么主服务器将对从服务器执行完整重同步操作。

3.服务器运行ID

除了复制偏移量和复制积压穿冲区之外，实现部分重同步还需要用到服务器运行ID：

• 每个Redis服务器,不论主服务器还是从服务,都会有自己的运行ID。
• 运行ID在服务器启动时自动生成,由40个随机的十六进制字符组成。

当从服务器对主服务器进行初次复制时,主服务器会将自己的运行ID传送给从服务器，而从服务器则会将这个运行ID保存起来。

当从服务器断线并重新连上一个主服务器时,从服务器将向当前连接的主服务器发送之1前保存的运行ID：

1.如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同,那么说明从服务器断线之前复制的就是当前连接的这个主服务器,主服务器可以继续尝试执行部分重同步操作。

2.如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同,那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器,主服务器将对从服务器执行完整重同步操作。