redis RDB如何进行同步的?

前言

redis集群同步方式有两种:

• RDB
• AOF

RDB

是什么?

RDB全名Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。

当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。

什么时候做备份?

RDB持久化在四种情况下会执行：

• 执行save命令
• 执行bgsave命令
• Redis停机时
• 触发RDB条件时

触发RDB条件

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1
save 300 10
save 60 10000

备份的文件名和位置都怎么配置?

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression no
# RDB文件名称
dbfilename dump.rdb
# 文件保存的路径目录
dir ./

RDB的基本原理是什么?

还记得linux系统编程的fork函数嘛? fork创建一个子进程, 父子进程通过 读时共享, 写时复制

redis也是使用的这项技术

RDB底层如何同步?

全量同步

1. slave 发送 sync 命令给 master
2. master 判断 slave 发送过来的 Replication Id 和 自己持有的 Replication id 是否相同
   1. 如果不相同, master就知道我需要执行全量备份了
   2. 如果是相同的, 那么配合 offset 进行增量备份
3. offset相当于告诉master的同步进度, 比如百分之70, 表示同步给slave百分之70的数据

增量同步

增量同步就是同步的 offset , 也就是同步进度

Q: 图中的 repl_baklog 是什么东西?
A: 这是一个循环队列, repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset, 然后就是slave的offset追赶master的offset进度的一个过程, 但是存在一个问题. 如果slave阻塞, 那么就可能覆盖master未同步的数据, 导致slave节点丢失了部分master的数据

上图展示了, master将slave未同步的信息给覆盖的场景

小结

RDB方式bgsave的基本流程？

• fork主进程得到一个子进程，共享内存空间
• 子进程读取内存数据并写入新的RDB文件
• 用新RDB文件替换旧的RDB文件

RDB会在什么时候执行？save 60 1000代表什么含义？

• 默认是服务停止时
• 代表60秒内至少执行1000次修改则触发RDB

RDB的缺点？

• RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
• fork子进程、压缩、写出RDB文件都比较耗时

AOF持久化

AOF是什么?

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

本质是将命令记录在 aof 相关文件中, 每次在redis客户端上执行命令, 就会将该命令保存在aof文件中

问题就来了

问: aof对同一个key的命令将会重复, 甚至还有多余的命令, 导致aof膨胀, 有什么办法优化?
答: 简单, aof重写机制

aof重写机制

是什么?

aof重写机制这么工作

a = 1;
a = 2;
a = 3;
a = 1;

经过aof重写后变成:

a = 1;

多余的命令全部清空掉

a = 2;
a = 3;
a = 1;

为什么需要aof重写?

aof配置文件内容易存在冗余指令(不影响最终结果的指令), 导致aof文件巨量膨胀

怎么进行AOF重写?

AOF 重写的触发机制分为两种：

1. 手动触发：通过向 Redis 发送 BGREWRITEAOF 命令手动触发 AOF 重写；
2. 自动触发：当 AOF 文件大小超过配置指定大小时，Redis 将自动触发 AOF 重写过程。

问: 自动触发制定大小如何配置?

答: 额定数值 + 百分比

auto-aof-rewrite-min-size 用于控制 AOF 文件自动触发重写的最小大小，默认值为 64MB。也就是说，当 AOF 文件的大小超过 64MB 时，Redis 会尝试自动触发 AOF 重写过程。

也可以通过 auto-aof-rewrite-percentage 这个配置项来控制 AOF 文件自动触发重写的百分比。例如，如果将该值设置为 100，表示在现有 AOF 文件的基础上增加的新命令占据当前 AOF 文件大小的 100% 时，Redis 就会自动启动 AOF 重写过程。不过需要注意的是，这个配置项必须与 auto-aof-rewrite-min-size 配合使用，否则可能会导致 Redis 处理 AOF 文件的行为不可预测。

AOF还有哪些需要关注的配置项?

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置:

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb

aof和rdb的区别是什么?

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

个人推荐rdb和aof机制一起使用, 防止数据丢失, 也防止aof没开启, 然后程序员在redis运行时, 发现只开启了RDB, 开启aof重启后, 出现数据丢失的情况

问答环节

在企业中我们应该如何防止redis数据丢失?

通常我们使用 rdb 和 aof 还不够, 需要添加 linux 脚本进行最后的保底, 一般是一天一次

目录结构:

启动linux备份shell, 定时执行该脚本

#!/bin/bash

# 备份目录
dir_arr=("6379/data" "6380/data" "6381/data")
bak_dir="/root/redis_cluster/bak"

# 当前时间
date=$(date '+%Y%m%d_%H%M%S')

# 检查并创建备份目录
if [ ! -d "$bak_dir" ]; then
    mkdir -p "$bak_dir"
fi

# 遍历目录备份文件
for dir in ${dir_arr[*]}; do
  if [ ! -d "$bak_dir/$dir/$date" ]; then
    mkdir -p "$bak_dir/$dir/$date"
  fi
  if [ "$dir" == "6379/data" ]; then
    cp -r "/root/redis_cluster/master/$dir/"* "$bak_dir/$dir/$date"
  else
    cp -r "/root/redis_cluster/slave/$dir/"* "$bak_dir/$dir/$date"
  fi
done

# 删除7天前的备份文件
echo "Deleting backup files older than 7 days in $bak_dir..."
# shellcheck disable=SC2038
find "$bak_dir/" -mindepth 1 -type d -mtime +7 | xargs rm -rf

实际上我们只需要保存 master 节点的数据就可以了(写操作一般针对master节点, 而非slave, slave节点一般配置了只读, 不可写), 不需要slave节点, 上面给出的脚本需要自己修改, 我主要是给了个模版, 到时候有多个master也可以修改

crontab -e 添加下面代码:

0 * * * * /bin/bash /root/redis_cluster/redis_rdb_copy_hourly.sh >/dev/null 2>&1