Redis-持久化RDB和AOF

1.RDB(Redis Database)

1.1 是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘 （Snapshot快照，它回复时是将快照文件直接读到内存里）
Redis会单独创建（Fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，等到持久化过程结束，在用临时文件替换上次持久化好的文件，整个过程中，主进程是不尽兴任何IO操作的，这就确保了极高的性能，如果需要进行大规模的数据的恢复，但是对于数据恢复的完整性不是非常的敏感，那么RDB比AOF 方式高效，RDB的缺点是最后一次持久化的数据可能会丢失。

1.2 Fork

Fork的作用是复制一个与当前进程一样的进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等等）数值都和原进程一直，但是是一个全新的进程，并作为原进程的子进程。如果原进程占用过大，复制一份进程则可能奔溃

1.3 Rdb保存的是dump.rdb文件

1.3.1配置位置

rdb存储的配置位于redis.conf文件下

################################ SNAPSHOTTING  ################################
#   save "" //如果不想使用rdb取消该注释
save 900 1 //15分钟 更改keys 1次
save 300 10 //5分钟 更改keys 10次
save 60 10000 //1分钟 更改keys 10000次
stop-writes-on-bgsave-error yes //出错后停止读写
rdbcompression yes //是否使用LZF算法建议开启，关了也没节省多少cpu
rdbchecksum yes //CRC64算法校验，增加10%的性能消耗
dbfilename dump.rdb //默认名称
dir ./  //默认保存在运行文件夹根目录下

1.3.2 如何触发Rdb快照

配置了save的触发条件后，redis就会按照你所配置的时间来触发snapshot，然后会在所配置的文件夹下生成dump.rdb文件

1.3.3 如何恢复

dump.rdb文件就是我们每隔一段时间备份到磁盘的数据集，正常来说应该在一段时间复制一份dump.rdb文件在别的服务器上进行冷拷贝，因为在我们执行flushall，或者shutdown命令的时候，运行目录下的dump.rdb文件会被覆盖在服务器宕机或者出问题时，我们就可以通过从别的服务器、磁盘上复制备份的dump.rdb文件覆盖运行文件夹下的dump.rdb文件来恢复数据库数据。
__注意：__如果在没有触发备份条件的时候又有觉得必要备份的数据，可以使用 save/bgsave命令触发备份，bgsave:redis会在会后要不进行快照操作，快照同事还可以响应客户端请求。通过lastsave命令获取最后一次成功执行快照的时间

1.4 优势/劣势

优势：适合大规模的数据恢复，对数据完整性和一致性要求不高
劣势：最后一次保存数据丢失风险大，fork子进程在数据集比较大的时候fork过程非常耗时，可能会导致redis在一些毫秒级不能响应客户端请求

2.AOF（Append Only File）

2.1 是什么

以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来（读操作不记录），只许追加文件不许改写文件，redis启动之初会读取改文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

2.2 AOF保存的是appendonly.aof文件

2.2.1配置位置

############################## APPEND ONLY MODE ###############################
appendonly no //是否开启aof持久化默认是no
appendfilename "appendonly.aof" //默认文件名
appendfsync everysec //三种持久化策略 everysec是出厂默认策略
//Always：同步持久化 每次发生数据变更立即记录到磁盘 性能较差但是数据完整性较好
//Everysec:出厂默认推荐，异步操作，每秒记录，若果一秒内宕机，有数据丢失
//no

2.3 AOF启动/修复/恢复

2.3.1 正常恢复

启动后，将现有数据的aof文件复制一份到对应的目录或者服务器，然后在系统宕机或者异常退出的时候覆盖原来的aof文件，重启redis然后重新加载

2.3.2 异常恢复

由于服务器宕机有可能导致aof文件损坏，那么我们应该首先备份被写坏的AOF文件，然后使用命令

Redis-checl-aof --fix //修复顺坏的aof文件

然后重启redis重新加载

2.4 Rewrite

2.4.1是什么

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

2.4.2 重写原理

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

2.4.3 触发机制

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

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

公司项目则基本是3G起步