Redis学习4（RDB和AOF）

Redis 提供了2个不同形式的持久化方式。

1. RDB（Redis DataBase）
2. AOF（Append Of File）

1.RDB（Redis DataBase）

（1）什么是RDB：在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

（2）备份恢复流程：Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

（3）RDB的缺点是最后一次持久化后的数据可能丢失。

        ---比如对redis配置文件的save进行改动后，设置20秒内3次操作以上才能写入dump.rdb文件。若是在最后一次操作还没达到3次时系统挂了，最后一次数据就丢了。

        ---在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

（4）rdb的恢复

1. 关闭Redis
2. 先把备份的文件拷贝到工作目录下，并命名dump.rdb-->        cp d1.rdb dump.rdb  
3. 启动Redis, 备份数据会直接加载

2.AOF（Append Only File）

（1）什么是AOF呢？它以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

（2）AOF的持久化流程是什么？

    1.客户端的请求写命令会被append追加到AOF缓冲区内；

    2.AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中（默认为 appendonly.aof）；

    3.AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；（重写相当于把一堆写的指令精简成一条长指令）

    4.Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的。

（3）数据的备份：AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件（appendonly.aof），需要恢复时再拷贝到Redis工作目录下，重新启动redis服务和客户端即加载。

（4）异常修复：若appendonly.aof文件存在异常，可以使用/usr/local/bin/redis-check-aof--fix进行修复。

（5）AOF的同步频率

        1.appendfsync always

                始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

        appendfsync everysec

                每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

        appendfsync no

                redis不主动进行同步，把同步时机交给操作系统。

3.AOF和RDB要记住的话：

（1）RDB优势：适合大规模的数据恢复，节省磁盘空间，恢复速度快

         RDB劣势：数据丢失风险大，最后一次持久化后的数据可能丢失。

（2）AOF优势：丢失数据概率更低

         AOF劣势：比起RDB占用更多的磁盘空间，恢复备份速度要慢。

RDB默认开启，AOF默认不开启。AOF和RDB同时开启，redis听AOF的。官方建议两个都开启，如果只是做纯内存缓存的话，两个都可以不用。若是对数据不敏感，允许部分丢失的话，可以考虑只开启RDB。