Redis持久化操作RDB和AOF及数据备份恢复方式

持久化的意义：Redis对数据的操作都是基于内存的，当遇到了进程退出、服务器宕机等意外情况，如果没有持久化机制，那么Redis中的数据将会丢失无法恢复。有了持久化机制，Redis在下次重启时可以利用之前持久化的文件进行数据恢复。

默认只有RDB开启，但是如果开启了AOF，系统默认读取AOF的数据因为AOF保存数据更完整

RDB（默认开启）

在指定的时间间隔内将内存中的数据集快照写入磁盘

触发方式

save和bgsave命令都可以手动触发RDB持久化

save

执行save命令会手动触发RDB持久化，但是save命令会阻塞Redis服务，直到RDB持久化完成。当Redis服务储存大量数据时，会造成较长时间的阻塞，不建议使用。

bgsave

执行bgsave命令也会手动触发RDB持久化，和save命令不同是：Redis服务一般不会阻塞。Redis进程会执行fork操作创建子进程，RDB持久化由子进程负责，不会阻塞Redis服务进程。Redis服务的阻塞只发生在fork阶段，一般情况时间很短。

RDB数据备份恢复方式

1.在conf文件配置一下假设20秒内至少有三个key变化就进行持久化操作

2.查看rdb文件 这时候大小是92

3.set几个值20秒后会进行持久化操作

4.这时候rdb大小改变了 说明成功了

5.先复制一份文件

6.这时候杀死redis进程并删除dump.rdb文件

7.重启redis后，发现里数据也都没了

8.先杀死redis，然后把d.rdb文件改成dump.rdb，然后再重启（刚刚重启redis只是为了看数据，改完数据需要再次重启），这时候会发现数据又回来了

优点

 适合大规模的数据恢复
 对数据完整性和一致性要求不高更适合使用
 节省磁盘空间
 恢复速度快

缺点

 Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

AOF（默认不开启）

以日志的形式来记录每次对数据的操作(增删改 读不算)到硬盘上。

AOF同步频率设置

appendfsync always
始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no
redis不主动进行同步，把同步时机交给操作系统

AOF重写机制

当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.

手动 ： bgrewriteaof 命令

自动 ：
根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage配置确定自动触发的时机。auto-aof-rewrite-min-size表示运行AOF重写时文件大小的最小值，默认为64MB；auto-aof-rewrite-percentage表示当前AOF文件大小和上一次重写后AOF文件大小的比值的最小值，默认为100。只用前两者同时超过时才会自动触发文件重写。

AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

AOF的启动和数据正常备份恢复

打开配置文件conf 搜素 appendonly 改成yes打开配置文件 配置完记得重启不然不生效

重启之后AOF数据还是0，对应redis数据空

而AOF的数据恢复和RDB一模一样这里就不演示了

AOF数据异常恢复方式

1.set几个文件，这时候文件会进入aof
2.vi appendonly.aof 进入文件加入一个随便单词我这里加的是problem然后！wq退出，这时候关闭redis，重启一定会报错


这时候输入命令 redis-check-aof --fix appendonly.aof 修复一下aof 就可以正常启动了（rs是我自己配置的快捷启动redis服务器命令，这个不重要）
要看的话看我这个博客：https://blog.csdn.net/Andrew0219/article/details/120348010
注意：redis-check-aof 前面要加你自己的redis路径我是因为就在~路径下所以不用加

优点

 备份机制更稳健，丢失数据概率更低。
 可读的日志文本，通过操作AOF稳健，可以处理误操作。

缺点

 比起RDB占用更多的磁盘空间。
 恢复备份速度要慢。
 每次读写都同步的话，有一定的性能压力。
 存在个别Bug，造成恢复不能。

总结

官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB。
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。

性能建议

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。
代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。
默认超过原大小100%大小时重写可以改到适当的数值