分布式缓存Redis6.x持久化配置实战-AOF和RDB

一、 Redis6.x持久化配置和RDB方式介绍

二、分布式缓存Redis6.x持久化配置RDB操作实战

三、Redis6.x持久化配置AOF介绍和配置实战 

四、Redis6.x持久化配置AOF重新rewrite配置实战

 五、 Redis6.x持久化配置AOF和RDB的选择问题

六、Redis4.0后开始的rewrite支持混合模式

一、 Redis6.x持久化配置和RDB方式介绍

Redis持久化介绍:
    Redis是一个内存数据库，如果没有配置持久化，redis重启后数据就全丢失
    因此开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。

两种持久化方式:
    RDB (Redis DataBase)
    AOF (append only file)
 
RDB持久化介绍:
在指定的时间间隔内将内存中的数据集快照写入磁盘
默认的文件名为dump.rdb

产生快照的情况：
save(手动在命令行写上执行)
    会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止
bgsave(手动在命令行写上执行)
    fork创建子进程，RDB持久化过程由子进程负责，会在后台异步进行快照操作，快照同时还可以响应客户端请求
自动化
    配置文件来完成，配置触发 Redis的 RDB 持久化条件
    比如 "save m n"。表示m秒内数据集存在n次修改时，自动触发bgsave
主从架构
    从服务器同步数据的时候，会发送sync执行同步操作，master主服务器就会执行bgsave

RDB优点:
    RDB文件紧凑，全量备份，适合用于进行备份和灾难恢复
    在恢复大数据集时的速度比 AOF 的恢复速度要快
    生成的是一个紧凑压缩的二进制文件
RDB缺点:
    每次快照是一次全量备份，fork子进程进行后台操作，子进程存在开销
    在快照持久化期间修改的数据不会被保存，可能丢失数据

二、分布式缓存Redis6.x持久化配置RDB操作实战

redis.conf配置文件触发RDB配置方式:

#任何ip可以访问
bind 0.0.0.0
​#守护进程
daemonize yes
​#密码
requirepass 123456789
​#日志文件
logfile "/usr/local/redis/log/redis.log"
​#持久化文件的文件名称
dbfilename wnn.rdb
​#持久化文件的路径
dir /usr/local/redis/data
​#关闭rdb的方式
#save ""
​#开启rdb的方式 多个直接换行加
#10秒2个key变动则触发rdb
save 10 2
#100秒5个key变动则触发rdb
save 100 5
​#压缩
rdbcompression yes
#检查
rdbchecksum yes

 更改后重启，然后连接上客户端，执行set语句

redis.log日志：刚的配置中10秒钟2个key变动则触发rdb ，当set name jack和set age 2进去之后，日志输出如下:

  控制台输入save和bgsave手动触发后的日志比较:

 RDB方式redis重启后的log日志:

注意:

  

备注: linux内存分配策略
0 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程
​1 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
2 表示内核允许分配超过所有物理内存和交换空间总和的内存
​
解决方式
echo 1 > /proc/sys/vm/overcommit_memory
​持久化配置
vim /etc/sysctl.conf
​改为
vm.overcommit_memory=1
修改sysctl.conf后，需要执行 sysctl -p 以使生效。

三、Redis6.x持久化配置AOF介绍和配置实战 

AOF持久化介绍:
    append only file，追加文件的方式，文件容易被人读懂
    以独立日志的方式记录每次写命令， 重启时再重新执行AOF文件中的命令达到恢复数据的目的
    写入过程宕机，也不影响之前的数据，可以通过 redis-check-aof检查修复问题
核心原理:
    Redis每次写入命令会追加到aof_buf（缓冲区）
    AOF缓冲区根据对应的策略向硬盘做同步操作
    高频AOF会带来影响，特别是每次刷盘
提供了3种同步方式，在性能和安全性方面做出平衡:
appendfsync always
每次有数据修改发生时都会写入AOF文件，消耗性能多

appendfsync everysec
每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no
不主从同步，由操作系统自动调度刷磁盘，性能是最好的，但是最不安全

配置实战:
    appendonly yes，默认不开启
    AOF文件名 通过 appendfilename 配置设置，默认文件名是appendonly.aof
    存储路径同 RDB持久化方式一致，使用dir配置

redis.conf配置文件触发AOF配置方式:

bind 0.0.0.0
​daemonize yes
​requirepass 123456789
​
logfile "/usr/local/redis/log/redis.log"
​
dbfilename wnn.rdb
​
dir /usr/local/redis/data
​
#save 10 2
#save 100 5
#关闭rdb方式
save ""
rdbcompression yes
#对rdb数据进行校验，耗费CPU资源，默认为yes
rdbchecksum yes
​

#默认不开启
appendonly yes
appendfilename "appendonly.aof"
#每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync everysec

重启后，连接客户端执行set命令

然后再查看appendonly.aof 里面存放的都是刚才执行的语句

具体策略的选择，还是根据实际的业务情况，需要在安全性跟性能上做一个选择。

四、Redis6.x持久化配置AOF重新rewrite配置实战

rewrite 重写介绍(压缩精简化):
    AOF文件越来越大，需要定期对AOF文件进行重写达到压缩
    旧的AOF文件含有无效命令会被忽略，保留最新的数据命令
    多条写命令可以合并为一个
    AOF重写降低了文件占用空间
    更小的AOF 文件可以更快地被Redis加载
重写触发配置:
    手动触发
        直接调用bgrewriteaof命令
    自动触发
        auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数
        #AOF文件最小重写大小，只有当AOF文件大小大于该值时候才可能重写,6.x默认配置64mb。
        auto-aof-rewrite-min-size 
        #当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比，如100代表当前AOF文件是上次重写的两倍时候才重写。　
        auto-aof-rewrite-percentage 

AOF常用配置redis.config:

# 是否开启aof
appendonly yes
​
# 文件名称
appendfilename "appendonly.aof"
​
# 同步方式
appendfsync everysec
​
# aof重写期间是否同步
no-appendfsync-on-rewrite no
​
# 自动重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
​
# 加载aof时如果有错如何处理
# yes表示如果aof尾部文件出问题，写log记录并继续执行。no表示提示写入等待修复后写入
​
aof-load-truncated yes 

 重复执行set 等语句后的aof日志：

 然后在客户端执行bgrewriteaof命令后的aof日志:

 压缩后的内容是二进制的很小也看不清楚内容。

然后继续执行set del等 语句

再直接打开aof日志查看: 压缩后的命令和刚进的命令是混合在一起的。

 五、 Redis6.x持久化配置AOF和RDB的选择问题

RDB的优缺点:
优点：
RDB最大限度地提高了Redis的性能，父进程不需要参与磁盘I/O(bgsave fork子进程)
RDB文件紧凑，全量备份，适合用于进行备份和灾难恢复
在恢复大数据集时的速度比 AOF 的恢复速度要快
生成的是一个紧凑压缩的二进制文件

缺点：
如果您需要在Redis停止工作时（例如断电后）将数据丢失的可能性降至最低，则RDB并不好
RDB经常需要fork才能使用子进程持久存储在磁盘上。如果数据集很大，Fork可能会非常耗时

AOF的优缺点：
优点：
数据更加安全
当Redis AOF文件太大时，Redis能够在后台自动重写AOF
AOF以易于理解和解析的格式，一个接一个地包含所有操作的日志

缺点：
AOF文件通常比同一数据集的等效RDB文件大
根据确切的fsync策略，恢复的时候AOF可能比RDB慢

在产线环境我们到底该怎么做？
RDB持久化与AOF持久化一起使用
如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据
集群中可以关闭AOF持久化，靠集群的备份方式保证可用性
自己制定策略定期检查Redis的情况，然后可以手动触发备份、重写数据；
采用集群和主从同步

六、Redis4.0后开始的rewrite支持混合模式

        就是rdb和aof一起用,直接将rdb持久化的方式来操作将二进制内容覆盖到aof文件中,rdb是二进制，所以很小
有写入的话还是继续append追加到文件原始命令，等下次文件过大的时候再次rewrite,默认是开启状态

好处:
    混合持久化结合了RDB持久化 和 AOF 持久化的优点,采取了rdb的文件小易于灾难恢复
    同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失

坏处:
前部分是RDB格式，是二进制，所以阅读性较差

数据恢复:
    先看是否存在aof文件，若存在则先按照aof文件恢复，aof比rdb全，且aof文件也rewrite成rdb二进制格式
    若aof不存在，则才会查找rdb是否存在