redis3 持久化RDB /AOF

redis 的持久化 ： ADB AOF

redis 是一个内存数据库，如果不想办法将内存中的数据持久化到磁盘中，一旦数据库进程结束，数据就会全部丢失。所以一定要将内存中的数据以一定的策略持久化到磁盘上。再次启动Redis 的时候就是用磁盘上的数据来还原数据。

RDB ：

干什么：
将一段时间间隔之后的内存快照（snapshot）保存到磁盘中；恢复数据的时候将数据从磁盘中从新读到内存中。
有关这一部分的配置：SNAPSHOT

如何触发RDB

1. 根据配置文件的配置，自动进行持久化

   # Save the DB on disk:
   #   save  
   
   #   save ""   # 如果不想使用自动ADB 就配置为空字符串
   
   save 900 1  # 900 s 内有一个key 被修改就会触发一次ADB
   save 300 10  # 300 s 内有十次key 修改就会触发ADB
   save 60 10000   # 60s 内有10000 次修改
   
   在测试的时候也可以自己对触发的时间点进行修改：格式： save  
   

   例如： 300s 内如果你修改了10 次key 那么300s 时间一到 ，就会将此时的内存快照持久化到磁盘中。

2. 手动触发

   1. 执行save,bgsave 指令，会立即执行持久化;save :只管存储，在持久化结束（dump.rdb 文件创建结束）之前，其他的请求都会阻塞。bgsave : 会异步的执行持久化，redis 依然能响应客户端的请求
   2. flushall ： 此时备份的数据是空的

RDB如何实现持久化
Redis 会单独的创建（fork）一个子线程完成持久化，首先会将数据写到一个临时文件中，待持久化过程都结束之后再用这个临时文件替换之前持久化好的文件。在整个过程中，主进程不会进行任何的I/O 操作，这样保证了主线程的高效性。（bgsave 是通过创建fork 子线程，但是save 是在当前的服务线程中完成持久化）
如果是需要大规模的数据恢复，且对数据恢复的完整性要求不高，那么ADB的性能要高于AOF。ADB的一个缺点在于：如果在最后一个持久化的时候刚好发生了异常，那么最后一次持久化的数据可能会丢失
fork : 复制一个和当前线程一样的线程完成持久化，新进程中的所有数据都是和原线程一样的，称为原线程的主线程。但是这样的复制，如果你的主线程十分大，那么在存储上的空间消耗就十分大。
ADB 持久化的结果就是生成一个 dump.rdb 文件
相关的配置：

# The filename where to dump the DB ： 持久化文件名
dbfilename dump.rdb

# Note that you must specify a directory here, not a file name. 持久化文件的存储位置，一个目录而不是文件名
dir ./

# permissions, and so forth.
stop-writes-on-bgsave-error yes
#  这一项设置为yes 之后。当redis 的持久化出现问题之后，redis 的写入也会直接停止。

如何恢复数据（文件载入和数据恢复）：
在实际的使用中会将数据备份另外的机器上，当前服务机器出现物理破坏导致数据再也无法恢复。

一般Redis启动的时候会自动载入dump.db。如果将备份文件(dump.rdb)移动到 redis 的安装目录启动服务即可。（config get dir 获取目录）。服务器在载入rdb 文件的时候服务器一直处于阻塞状态。

总结：
优势：

1. 适合大规模的数据备份
2. 对数据的一致性要求不高

劣势：

1. fork 新的线程处理持久化，内存的消耗会变大
2. 最后一次的数据备份可能会丢失

停止ADB 配置save ""/或者命令取消：redis-cll config set save "" 但是一般不会

AOF

AOF 主要是解决ADB产生的一些问题,例如最后一次数据丢失。但是在实际操作中最后一次数据丢失也没有太大的影响，毕竟有运维人员专门对数据进行恢复。比如你的redis 15 分钟进行一次ADB，找回15 分钟的数据还是不难的。

干什么：
Redis 每进行依次写操作就会把该命令写入aof_buf 一个缓存区中，在不同的同步时机设置下把aof_buf 中的内容写入磁盘中(aof 文件中)。redis 在重启的时候会重构数据，就是将aof 文件中的写指令都再执行一遍。

在启动的时候如果dump.rdb , appendonly.aof 都存在，那么首先会加载.aof
修复aof 文件：redis-check-aof --fix appendonly.aof 命令执行会自动修复文件

aof 模式：
aof 的相关配置：

# 默认的是关闭的
appendonly no

#默认设置的文件名
appendfilename "appendonly.aof"

#数据持久化的时机
# appendfsync always   # 只要改变了数据就要进行持久化，这样I/O 操作频繁，效率会极低
appendfsync everysec # 默认使用；异步操作，每隔一秒会将aof_buf 中的数据写入磁盘，就算数据丢失也只丢失一秒的
# appendfsync no # 只管将指令写入aof_buf 不管何时进行同步

文件载入/数据恢复：

重写：Rewrite
为了解决AOF文件体积不断膨胀的策略
aof 是追加的方式，文件会越来越大，为了避免这种情况的出现，新增重写机制。当文件的大小达到某个阈值的时候，AOF 就启动文件压缩，只保留可以恢复文件的最小指令集，使用命令 bgrewriteaof
重写原理： fork 出一条新的线程进行重写任务
触发重写的时机:

auto-aof-rewrite-percentage 100  # 比上一次rewrite 后的大小大一倍
auto-aof-rewrite-min-size 64mb   # 并且超过64mb

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

劣势： aof的文件要比rdb 的文件大很多

如果在数据库中开启了AOF功能会首先使用AOF还原