转：https://blog.csdn.net/weixin_62319133/article/details/124584514
一、Redis的持久化
本章节会比较多的讲到所有关于Redis持久化的配置，平时使用场景会非常的少，对初学者可能不是很友好，如果仅仅是如何使用的话可以直接跳到RDB和AOF使用，小标题我标了红色，直接跳过去看就可。
RDB默认开启，AOF默认关闭。具体如何搭配及策略选择可以根据业务需求灵活搭配。
1、Redis的持久化概念
因为Redis数据基于内存读写，为了防止Redis服务器关闭或者宕机造成数据丢失，我们通常需要对Redis最磁极化，即：把内从中的数据(命令)保存一份到磁盘做一个备份，当Redis服务关闭或者宕机，
在Redis服务器重启的时候会从磁盘重新加载备份的数据，不至于数据丢失。 Redis 提供了两种不同级别的持久化方式：RDB和AOF,可以通过修改redis.conf来进行配置.
开启持久配置后，对Redis进行写操作，在Redis安装目录将会看到持久文件：“appendonly.aof”和“ dump.rdb”。
2.Redis如何保保存数据
众所周知，Redis是通过AOF和RDB进行数据的持久化存储，
Redis为了考虑效率,保存数据在内容中.并且考虑数据安全性,还做数据持久化,如果满足保存策略，就会把内存的数据保存到数据rdb文件，还来不及保存那部分数据存放到aof更新日志中。在加载时，把两个数据做一个并集。
3.RDB
3.1.RDB概念及原理
RDB是Redis DataBase的缩写，意为内存快照。因为Redis的数据时保存在内存中的，就意味着每当我的服务重启时都会导致内存中的数据丢失，这时候就需要RDB来进行数据恢复了。RDB就是说它每隔一段时间，会将Redis中的数据以RDB文件格式的形式对数据进行一个保存。在我们的服务重启后Redis会自动找到RDB文件中存储的数据并加载到内存中。
RDB又有两种持久化方案，分为全量快照和增量快照，这个有机会再跟大家介绍。日常生产中学会这些已经完全足够，如果需要极致优化的话可以私信或者留言，再跟大家进一步介绍。
简单理解，就是每隔一段时间，Redis会对数据进行一次快照，并通过压缩后的二进制文件，就是RDB文件将数据保存在磁盘中。
3.2RDB的特点（这里的特点基本都是对照AOF的优缺点）
1.适合较大规模的数据恢复。
2.文件体积相对较小，节约磁盘空间。
3.恢复速度快。
4.不能完全保证数据不丢失，因为它是每隔一段时间进行一次持久化，也就意味着在上一次执行完快照到下一次执行快照之前的数据无法进行持久化。
5.RDB是默认开启的
3.3.如何使用RDB
我们在Redis的配置文件 redis.conf 中可以看到
注意：Redis默认开启RDB，关闭的话注释掉即可
#save 900 1 # 900sec(15分钟)后，如果至少有一个键改变(就进行持久化)
#save 300 10 #在300秒(5分钟)后，如果至少10个键改变(就进行持久化)
#save 60 10000 #在60秒后，如果至少有10000个键被更改(就进行持久化)
4.AOF
4.1.AOF概念及原理
AOF是Append Only File的缩写，是以独立日志的方式记录每次写操作的命令，服务重启时再重新执行AOF文件中的命令达到恢复数据的目的。既然我们已经有了RDB为什么还需要AOF呢
相信用过Eclipse的同学应该都有过在电脑蓝屏或者Eclipse非正常关闭情况下的痛，我们每写完一段代码都需要疯狂ctrl+s进行保存，但是我们在上一次保存之后到下一次保存之前的这个窗口期的新增代码只能忍痛再来一遍。Redis也是同理，因为RDB是每隔一段时间对数据进行一次快照，就是说他会有一个窗口期，对于我们写代码来说无非就是忍受痛苦咬牙再来一遍，但是对于有些业务，是不能容忍数据丢失的，这时候就需要结合AOF来进行持久化存储。他使用颗粒度更细的方式，通过记录每一条命令进行数据的持久化。
但是颗粒度更细意味着需要更多的内存，更低的性能和更慢的速度，所以一般我们都会结合RDB一起使用。
AOF会以日志的形式记录一段时间内的写操作（包括insert和update操作）。
每次对Redis中的数据进行写操作时都会新增一条修改内容的记录
每次在Redis重启后会根据AOF中记录的指令从头到尾执行一次
4.2.AOF的特点
1.AOF的备份机制更加靠谱
2.因为AOF是记录命令的形式，就是说我们可以通过AOF文件处理错误操作
3.占用较大的磁盘空间
4.恢复速度相对较慢
4.3.如何使用AOF
同样，在配置文件中可以看到，不同的是AOF的配置比RDB要多一些，挨个跟大家介绍一下
4.3.1开启AOF
appendonly yes #AOF默认为no，不开启AOF，如果我们要开启的话修改为yes即可
4.3.2.日志文件输出名称及策略
appendfilename "appendonly.aof" #文件输出的文件名,默认为"appendonly.aof"
#同步的频率
appendfsync always #每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
appendfsync everysec #每秒同步一次（默认值，相对折中）
appendfsync no #等操作系统进行数据缓存同步到磁盘（快）
4.3.3.日志文件输出配置1
当AOF fsync策略设置为always或everysec的时候，可能会产生后台保存AOF日志时对磁盘执行大量I/O的情况，可能会导致我们的Redis阻塞很长时间。 这个问题目前暂时还没有解决，因为即使在不同的线程中执行fsync也会阻塞我们的同步写操作。
也就是说在 AOF rewrite 期间，对 AOF 新记录的 append 不开启文件同步策略,主要考虑磁盘 IO开支和请求阻塞时间。默认为不开启，新的 AOF 记录会被立即同步。
no-appendfsync-on-rewrite no #no为不开启（默认为no），yes为开启
4.3.4日志文件输出配置2
auto-aof-rewrite-percentage 100
#当输出的文件增长超过指定比例时，重写日志文件
#设置为 0 表示不自动重写AOF日志文件,设置为 100 时表示每次操作都会重写AOF日志文件（满足下面条件时）
#重写是为了确保数据完整的情况下，AOF文件所占的磁盘空间最少
auto-aof-rewrite-min-size 64mb
#当文件大于这个最小尺寸（64MB）时才会触发重写，否则文件太小重写也没有意义
4.3.5日志文件读取
当Redis读取磁盘中的AOF文件时出现了问题，如果设置为yes，就发出日志通知用户这个事件，并继续启动。如果设置为no时，就抛出错误并拒绝启动。当设置为no，并且AOF文件出现损坏时，需要使用 "redis-check-aof" 工具来修复AOF文件，如果无法修复依然会报错并拒绝启动。
aof-load-truncated yes #yes开启（默认yes），no关闭
5.数据备份与恢复
5.1.数据备份
虽然配置了持久化Redis会进行自动数据备份，我们也可以通过 SAVE 或者BGSAVE (后台备份)命令创建当前数据库的备份
save #执行该命令将在 redis 安装目录中创建dump.rdb文件。
5.2.数据恢复
将dump.rdb 文件移动到 redis 安装目录并启动服务即可。
————————————————
版权声明：本文为CSDN博主「丁胜利v」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_62319133/article/details/124584514
