redis持久化（RDB、AOF）

redis是内存数据库，但是不仅限于内存，redis有其持久化的方式；

共有三种持久化的方式；

方式1：生成dump.rdb文件

方式2：生成appendonly.aof文件

方式3：master/slave（主从复制读写分离）

RDB：（redis database）

简介：   

   通俗来说，rdb是在指定的时间间隔内将内存中的数据集快照写入磁盘，即snapshot快照，想要恢复时，将快照文件（dump.rdb文件）直接读取，即可恢复到内存中；

    redis会单独fork一个子进程来进行持久化，先将数据写入一个临时文件，等持久化结束了（即该临时文件写好了），将该临时文件替换上一次持久化生成的rdb文件；整个过程中，主进程不进行任何的IO操作；

      rdb有一个缺点：最后一次持久化的数据可能丢失；因为按照时间段进行快照；

细节：

Rdb：默认状态

Save 900 1      300秒内未达到10次，在900秒内达到1次，备份

Save 300 10    60秒内未达到10000次，在300秒内达到10次，备份

Save 60 10000   60秒内达到10000次，备份（这个备份不是立刻的，即使在50秒达到了10000次，也需要等到60秒才会生成dump.rdb文件）

用save，bgsave命令可以直接备份，不需要等待上述条件；

save：只管保存，其他不管，全部阻塞；（即在写入dump文件的时候，redis占用的内存中不能执行写入操作）

bgsave：redis会在后台异步进行快操作，快照的同时还可以响应客户端请求，可以通过lastsave命令获取最后一次成功执行快照的时间；

陷阱：

1. flushall命令：消除全部的内存中的redis数据，并即刻产生一个dump.rdb文件，但由于清空了，所以该文件记录的是空；

2. shutdown命令： 通过redis-cli SHUTDOWN停掉redis，是一种安全退出的模式，redis在退出的时候会将内存中的数据立即生成一份完整的rdb快照。

3. 在redis中再保存几条新的数据，用kill -9 粗暴杀死redis进程，模拟redis故障异常退出，导致内存数据丢失的场景；

这次就发现，redis进程异常被杀掉，数据没有进dump文件，几条最新的数据丢失了；

4. 机器突然挂掉，可能会使得最近几分钟的数据无法恢复；

5. 一般生成dump.rdb文件后会再次将该文件备份到其他机器上面，恢复时，将dump.rdb文件复制到redis目录下，启动即可

 

知识点：判断redis启动的方式

方法一：ps -ef|grep redis

方法二：lsof -i :6379

知识点：启动redis的方式(先后启动以下两条命令)

redis-server /myredis/redis.conf

redis-cli -p 6379

知识点：在Linux中看磁盘空间和内存空间的命令

df –h 看磁盘空间

 free  看内存空间

---------------------------------------------------------------------------------------------------------------------------------------------

以下是从博客中摘的一段更为细节一点的解释：https://blog.csdn.net/why15732625998/article/details/80565044

2.1 配置RDB持久化机制

在redis.conf文件，也就是我们这里的/etc/redis_6379/6379.conf去配置RDB持久化

save 60 1000

每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting,快照也可以手动调用save或者bgsave命令，同步或异步执行rdb快照生成。

save可以设置多个，就是多个snapshotting检查点，每到一个检查点，就会去check一下，是否有指定的key数量发生了变更，如果有，就生成一个新的dump.rdb文件。如下配置：

save 900 1
save 300 10
save 60 10000

2.2 基于RDB持久化机制的数据恢复实验

1.在redis中保存几条数据，立即停掉redis进程，然后重启redis，看看刚才插入的数据还在不在,为什么?

通过redis-cli SHUTDOWN这种方式去停掉redis，其实是一种安全退出的模式，redis在退出的时候会将内存中的数据立即生成一份完整的rdb快照。

2.在redis中再保存几条新的数据，用kill -9 粗暴杀死redis进程，模拟redis故障异常退出，导致内存数据丢失的场景

这次就发现，redis进程异常被杀掉，数据没有进dump文件，几条最新的数据丢失了

3.手动设置一个save检查点， save 5 1
如果启动报pid已经存在，则先删除/var/run/redis_6379.pid

rm -rf redis_6379.pid

写入几条数据，等待5秒钟
停掉redis进程，再重新启动redis，看刚才插入的数据还在不在，这时我们发现数据可以顺利恢复。

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

AOF：

简介：

aof用文件追加方式，是通过对日志记录的方式实现持久化，记录所有的写操作，生成appendonly.aof文件，恢复时只需在启动时读取该文件即可；

redis.conf文件中，默认为appendonly no，改成yes，启动aof机制；

细节：

1. 如果两种恢复（备份）策略，同时存在，那听谁的？

先找appendonly.aof文件（忽略dump.rdb）

2. 若aof文件损坏，可以通过如下命令修复aof

redis-check-aof --fix appendonly.aof

rdb文件恢复则是，redis-check-dump

3. appendsync：默认设置为everysec，持久化的参数设置，异步操作，每秒记录，如果一秒内宕机，有数据丢失；

该参数还有 always和No。分别表示同步持久化（性能差）和不持久化；

4. rewrite：aof文件的瘦身机制，压缩那个优化aof文件

5. no-appendfsync-no-rewrite：重写时运用appendsync，no-appendfsync-no-rewrite用默认的no即可，保证重写时数据安全性；

 

 

如何选择：

1.快速恢复和备份，对数据敏感性，完整性，要求不高--------单独使用rdb即可；

2.建议同时使用aof和rdb

3.建议不要单独使用aof

 

master/slave：

主从复制是为了

1.读写分离，减小io压力

2.备份

该模式常用，持久化方案基础还是rdb和aof，但是有其特殊的策略；

本章节暂不介绍...