RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point–in–time snapshot）。实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存在。
RDB 持久化
redis6.0.16以下
save 900 1:每隔900s(15min)，如果有超过1个key 发生了变化，就写一份新的RDB文件
save 300 10:每隔300s(5min)，如果有超过10 个key发生了变化，就写一份新的 RDB文件
save 60 10000:每隔60s(1min)，如果有超过10000个key 发生了变化，就写一份新的RDB文件
redis6.2以上
save 3600 1:每隔3600s(1小时)，如果有超过1个key 发生了变化，就写一份新的RDB文件
save 300 10:每隔300s(5min)，如果有超过100个key发生了变化，就写一份新的 RDB文件
save 60 10000:每隔60s(1min)，如果有超过10000个key 发生了变化，就写一份新的RDB文件
1、修改配置文件：redis.conf
2、RDB模式自动触发保存快照
/data# redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "123456"
127.0.0.1:6379> config get dir
1) "dir"
2) "/data"
测试：
测试前
[root@localhost data]# ll
总用量 4
-rw-------. 1 polkitd input 392 11月 21 21:49 dump.rdb
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
测试后
[root@localhost data]# ll
总用量 8
-rw-------. 1 polkitd input 107 11月 22 21:20 dump3679.rdb
-rw-------. 1 polkitd input 392 11月 21 21:49 dump.rdb
redis重启就会读取快照恢复，执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
3、RDB模式手动触发保存快照
Redis提供了两个命令来生成RDB文件，分别是save和bgsave
save：在主程序中执行会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用
BGSAVE(默认)：Redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，触发方式会fork一个子进程由子进程复制持久化过程
4、RDB的优缺点
RDB的优点
1、适合大规模的数据恢复
2、按照业务定时备份
3、对数据完整性和一致性要求不高
4、RDB 文件在内存中的加载速度要比AOF快得多
RDB的缺点
1、在一定间隔时间做一次备份，所以如果redis意外宕机的话,就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失
2、内存数据的全量同步，如果数据量太大会导致I/0严重影响服务器性能
3、RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一俯，大致2倍的膨胀性，需要考虑
修复RDB文件
进入bin目录找到：redis-check-rdb 命令，指定rdb文件
AOF持久化
默认情况下，redis是没有开启AOF(append only file)的。
1、AOF持久化工作流程
1、Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2、在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
3、AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。
4、随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。
Always：同步写回，每个写命令执行完立刻同步地将日志写回磁盘。
everysec：每秒写回，每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘。
no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
2、修改配置文件开启AOF
策略为默认
文件保存路径
redis6：AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置
redis7：相对于redis6会多建一个appendonlydir文件路径
文件名称
redis6只有一个文件
redis7由Multi Part AOF的设计变成3个文件：base基本文件，incr增量文件，manifest清单文件
示例：开启AOF，写入数据
“AOF is valid” 表明 AOF 文件是有效的，没有发现任何问题。
3、AOF优缺点
AOF缺点：相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdbaof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同。
由于AOF持久化是Redis不断将写命令记录到AOF文件中，随着Redis不断的进行，AOF的文件会越来越大，文件越大，占用服务器内存越大以及AOF恢复要求时间越长。
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
4、AOF的重写机制原理
1、在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
2、与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
3、当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。
4、当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中。
5、重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
RDB+AOF混合模式
当RDB，AOF都存在时，redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文供保存的数据集要完整。RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。
那么只使用AOF呢?
建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。
原文地址:https://blog.csdn.net/qi341500/article/details/134519302
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.7code.cn/show_7039.html
如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！
