本文共 3456 字，大约阅读时间需要 11 分钟。

持久化方式

redis主要工作在内存中。内存本省就不是一个持久化的设备，断电后数据会清空。但是redis提供了持久化方式。个人看来 这是redis提供了一种备份机制，可以将内存中的数据持久化到磁盘上，有利于这些热点数据的备份恢复和迁移。

redis提供了两种持久化方式，分别是RDB 和AOF

RDB持久化方式能够在指定的时间间隔对数据进行快照存储

AOF持久化方式记录每次对服务器的写操作，当服务器重启的时候会重新执行这些命令来恢复原始数据，个人认为类似于MySQL的binlog日志

RDB

RDB：在指定的时间间隔内将内存中的数据写入磁盘，它恢复时是将文件读取到内存中。

RDB是默认开启的

RDB工作机制

工作机制：每隔一段时间，就会把内存中的数据保存到硬盘上的指定文件中。

RDB在持久化时会单独创建一个fork子进程来进行持久化操作，会先将数据写入到一个临时文件中，等到持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程work是不会进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模的数据恢复，RDB性能比AOF好很多。

保存策略

save 900 1 900 秒（15分钟）内如果至少有 1 个 key 的值变化，则保存

save 300 10 300 秒（5分钟）内如果至少有 10 个 key 的值变化，则保存 save 60 10000 60 秒（1分钟）内如果至少有 10000 个 key 的值变化，则保存 save “” 是禁用RDB模式

RDB属性设置

属性	含义	默认
save	保存策略	默认开启三个 也就是15分钟1个key则保存
dbfilename	RDB 快照文件名	dump.rdb
dir	RDB 快照保存的目录	必须是一个目录，不能是文件名。最好改为固定目录。默 认为./代表执行 redis-server 命令时的当前目录！
stop-writes-on-bgsave-error	是否在备份出错时，继续接受写 操作	如果用户开启了 RDB 快照功能，那么在 redis 持久化数据 到磁盘时如果出现失败，默认情况下，redis 会停止接受所 有的写请求
rdbcompression	对于存储到磁盘中的快照，可以 设置是否进行压缩存储。	如果是的话，redis 会采用 LZF 算法进行压缩。如果你 不想消耗 CPU 来进行压缩的话， 可以设置为关闭此功能，但是存储在磁盘上的快照会 比较大。
rdbchecksum	是否进行数据校验	在存储快照后，我们还可以让 redis 使用 CRC64 算法 来进行数据校验，但是这样做会增加大约 10%的性能消耗， 如果希望获取到最大的性能提升，可以关闭此功能。

触发持久化的方式

1、基于自动保存策略

2、执行save，或者bgsave命令，执行时save时是阻塞状态 3、执行 shutdown 命令时，也会主动地备份数据。 4、执行 flushdb 命令，也会产生 dump.rdb，但里面是空的，没有意义

优缺点

优点

1、RDB是一个文件，保存了某个时间点的数据集，非常适合用于数据集的备份。 2、压缩格式 恢复速度快 缺点 1、（可能有 但是我没找到）没有设置固定大小的策略，随着业务量的增加 只能任由rdb文件增大 2、不是实时的，可能会丢数据，操作比较重。 3、fork时内存中的数据被克隆了一份，大概2倍的膨胀。 备份脚本

每小时备份一次rdb文件 crontab  -e0 */1 * * * cp /etc/redis/dump.rdb  /etc/redis/dump.rdb`date +%Y%m%d%H`

AOF

1、AOF是以日志的形式来记录每个写操作，将每一次对数据进行修改，都会把新建、修改数据的命令保存到指定文件中。redis重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。

2、默认不开启，需要手动启动 3、AOF 在保存命令的时候，只会保存对数据有修改的命令，也就是写操作！ 4、当 RDB 和 AOF 存的不一致的情况下，按照 AOF 来恢复。因为 AOF 是对 RDB 的补充。备份周期更短，也就更可靠。

保存策略

appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！

appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即 1 秒钟的数据）。

appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全的选择。推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

AOF属性设置

属性	含义	默认
appendonly	是否开启 AOF 功能	默认是关闭的
appendfilename	AOF 文件名称
appendfsync	AOF 保存策略	官方建议 everysec
no-appendfsync-on-rewrite	在重写时，是否执行保存策略	执行重写，可以节省 AOF 文件的体积；而且在恢复的时候 效率也更高。
auto-aof-rewrite-percentage	重写的触发条件	当目前 aof 文件大小超过上一次重写的 aof 文件大小的百分 之多少进行重写
auto-aof-rewrite-min-size	设置允许重写的最小 aof 文件 大小	避免了达到约定百分比但尺寸仍然很小的情况还要重写
aof-load-truncated	截断设置	如果选择的是 yes，当截断的 aof 文件被导入的时候，会自 动发布一个 log 给客户端然后 load

AOF文件的修复

如果 AOF 文件中出现了残余命令，会导致服务器无法重启。此时需要借助 redis-check-aof 工具来修复！

命令： redis-check-aof –fix 文件

AOF的rewrite机制

AOF采用文件追加方式，文件会越来越大，为了避免出现这种情况，新增加了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof

重写原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件重新（也就是先写临时文件最后rename），遍历新进程的内存中数据，每条记录有一条set语句。重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件，这点和RDB快照相似。

触发机制

redis会记录上次重写时AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大小大于64M时触发。

优缺点

优

1、备份机制更稳健，丢数据概率更低 2、可读的日志文本，通过操作AOF文件，可以处理误操作。 缺 1、比起RDB占用更多的磁盘空间 2、恢复备份速度要慢 3、每次读写都同步的话，有一定的性能压力

两种备份方式的有优先级

如果同时开启两种持久化方式： 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

RDB的数据不是实时的，同时使用两者时服务器重启也只会找AOF文件。那要不要只用AOF呢？

也不建议，因为RDB更适合备份数据库，进行快速重启。

应用场景

一、服务器卡死或者redis卡死

如果数据不是很重要 建议直接使用RDB恢复。 恢复步骤： 1、移动AOF文件（因为默认是从AOF文件reload） 2、检查RDB文件 进行redis restart 重新reload RDB文件

二、人为误删除部分数据

数据不重要：删除了就删除吧 数据重要：AOF恢复

三、人为误删除全部数据

数据不重要：使用crontab 定时备份任务 备份的RDB文件进行恢复 数据重要：使用AOF的方式，vim appendonly.aof文件，将flushall命令删除后进行重启redis 四、误删除AOF文件 误删除了 就是没了。只能从现在再开始记录。 五、误删除RDB文件 save \bgsave触发条件会再次自动生成dump.rdb 是无所谓的

转载地址：https://liushiya.blog.csdn.net/article/details/115327702 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！