1.高并发redis - 持久化备份方案

redis几乎是我们在实际开发过程中提升效率必须用到的工具，特别在高并发场景下，
redis号称单机10w+qps，除了高qps，数据安全也是一个系统必须考虑的部分，
redis数据持久化是保证数据安全一个重要环节，所以现在就来讨论一下redis持久化相关内容。

会讨论一下以下几个方面

• 1、redis数据持久化的作用
• 2、redis的持久化，RDB，AOF区别，各自特点，适合什么场景
• 3、生产环境数据冷备和热备的方案
• 4、用docker启动单机redis（带生产环境redis配置）
• 5、容灾演练

1、redis数据持久化的作用

• 1.主要是故障恢复。
  • 因为redis程序运行过程中，总会遇到一些不可预测的问题，比如机器down了，
    docker空间满了挂了，redis内存满了，等等一系列问题。
• 2.高可用的一个环节。
  • 当数据恢复，能保证redis重启后快速投入使用
  • 如果重启后，没有数据恢复，就会产生缓存雪崩问题，
    所有请求都会打到数据源头mysql，过万的qps打到mysql，那么mysql一下就挂了。

缓存雪崩.png

2、redis的持久化，RDB，AOF区别，各自特点，适合什么场景

RDB

对redis数据执行周期性备份，每隔一定时间（自己设置），生成redis内存中的数据的一份完整的快照（rdb文件）
配置后生成的文件是.rdb后缀的，纯数据文件，不便于阅读。

rdb文件内容示例-二进制压缩.png

AOF

.aof后缀文件是记录每条操作指令的文件，基本可读。
现在操作系统写文件不是直接写磁盘，会先写os cache，然后操作系统每隔一秒调用fsync操作，把数据从os cache到磁盘，只有到了磁盘，数据才是安全的。
没有一条指令，就会往os cache写一条命令，然后设置每秒做一个fsync，把指令写到磁盘
如果同时有aof和rdb文件，优先使用aof文件去恢复数据，因为里面的数据比较完整。

aof文件内容.png

• fsync ：把os cache的数据写到磁盘的aof文件中
• rewrite：.aof文件记录每一条指令，所以它会越来越大，当到达一个配置设置值的时候
  ，就会基于当前redis数据，重新生成一份aof文件来压缩体积。
  • 例如现在设置了一个 set name along;
  • 有执行了一个 del name ;
  • 此时.aof文件存了这两条指令，但是数据没变化，所以rewrite压缩的时候，可以把这个的无效指令去掉
• appendfsync：把os cache数据刷到磁盘的评率。
  • 如果把appendfsync设置为always，相当于是每次写磁盘了 那么吞吐量很低。

  • mysql最多1-2k，redis单机一般来说，上万-几十万。如果设为always，就基本是基于磁盘只有1-2k了。设为everysec，qps也上万

    
    AOF和RDB介绍.png

AOF和RDB文件对比

rdb的优点：

• rdb会生成多个数据文件，每个数据文件都代表了某一个时刻redis中完整的数据，多文件的方式，适合做冷备份。
• rdb是redis效率最高的，因为他会fork一个子进程去操作。
• 相当与aof持久化机制，直接基于rdb数据文件来重启和恢复redis进程，更加快速。
  • 因为rdb是数据文件，直接加载入内存，而aof是在redis中把之前执行过的指令一一执行一遍。
• rdb做冷备，是由redis定时生成文件，比较方便
• rdb每次都是写内存的，一定时间才会fork进程去写文件，而aof是每次都写文件
  rdb的缺点：
• 很明显，会造成数据的丢失（最主要缺点）
  • 例如每隔5分钟写一次，那么如果刚写完一次，
  • 过了四分钟，还没来得及写下一次，但是redis挂了，没来的写下一次，那么，这四分钟的数据就丢了。
• 如果每次rdb时间间隔设置过长，数据过多，fork进程写数据的时候会导致redis去处理rdb，而暂时不能提供服务（几秒或者数秒）
  aof的优点：
• aof可以很好的保护数据不丢失，因为aof每隔一秒，在后台执行一次fsync操作，做多丢失1秒数据
• aof日志文件以append-only模式写入，所以没有磁盘寻址的开销，写入效率很高。
• 会fork一个进程把老文件整合，整合完毕，然后就把老文件删了（rewrite）
• aof文件是指令文件，可读的。
  aof的缺点：
• 数据恢复会比较慢
  • 指令文件，同样数据，肯定比rdb数据文件大，执行时间长。
• 一般设置每秒一次fsync操作，相比rdb会增加一些额外开销。

3、生产环境数据冷备和热备的方案

首先在生产环境，aof和rdb都是必须打开的，因为数据安全的重要性不言而喻，保证数据的最少丢失。
一般都是配套使用

• 首先 appendonly yes; appendfsync everysec; 开启每秒的aof
• 然后save 300 1000; 开启每5分钟的rdb，数据量根据业务来
• 数据冷备份方案：
  • 写crontab定时调度脚本去做数据备份
  • 每小时都copy一份rdb的备份，到一个目录，仅仅保留最近48小时的备份
  • 每天都保留一份当日的rdb备份，到一个目录中去，仅仅保留最近一个月的备份
  • 每次copy备份的时候，都把太久的备份给删掉
  • 每天晚上把当前服务器上所有的数据备份，发送一份到远程云服务上去。

相关脚本
redis_rdb_copy_daily.sh 备份30天

# 先创建当天的
cur_date=`date +%Y%m%d`
rm -rf /data/rdb_back/$cur_date
mkdir /data/rdb_back/$cur_date
cp /data/dump.rdb /data/rdb_back/$cur_date

# 然后删除一个月之前的
del_date=`date -d -1month +%Y%m%d`
rm -rf /data/rdb_back/$del_date

redis_rdb_copy_hourly.sh 48小时的

cur_date=`date +%Y%m%d%k`
rm -rf /data/rdb_backup/$cur_date
mkdir /data/rdb_backup/$cur_date
cp /data/dump.rdb /data/rdb_backup/$cur_date

del_date=`date -d -48hour +%Y%m%d%k`
rm -rf /data/rdb_backup/$del_date

添加定时器脚本

crontab -e
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
0 0 * * * sh /data/redis/sh/redis_rdb_copy_daily.sh

测试sh脚本方法为，手动执行这两个sh脚本，自定义时间，看能不能在对应文件夹生成文件。

注意：这里直说冷备方案，因为后面会将主从复制和哨兵之类的，通过节点切换来完成热备份高可用。

4、用docker启动单机redis（带生产环境redis配置）

用docker起动单个redis：redis.conf放在/data/redis/redis.conf
redis.conf

#下面包括了密码，rdb的设置，aof的设置，和工作目录地址
port 6379
requirepass "123456"
dbfilename "dump.rdb"
dir "/data"
logfile "/data/redis.log"
save 300 20
appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 1mb

docker启动脚本

# 挂载/data/redis/ 到 redis.conf设置的dir中
docker run -d --name redis1 -p 6379:6379 -v /data/redis/:/data/ redis redis-server /data/redis.conf

启动后进入容器，随便设置几个key，然后退出来，就会发现，/data/redis 下面就会多出了rdb，aof，log等文件

docker启动reids后多出来文件.png

5、容灾演练
模拟redis直接挂掉，然后进行数据恢复的过程。

• 首先直接在docker中把redis的container删掉
• 然后查看/data/redis/下面的aof文件是否存在
• 存在的话用上面docker启动指令再次启动reids
• 进入容器内的redis-cli，查看刚才设置的key，是存在的，这就说明数据备份成功。