Redis持久化---RDB和AOF

目录

一、RDB方式持久化

1、什么是RDB

2、配置位置及SNAPSHOTTING解析 

3、优点和缺点

二、AOF方式持久化

1、什么是AOF

2、配置AOF

3、优点和缺点

三、总结

---

一、RDB方式持久化

1、什么是RDB

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

        Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量，环境变量，程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

       默认使用的是RDB,rdb保存的文件是dump.rdb。该文件名可以在配置文件中修改。

2、配置位置及SNAPSHOTTING解析 

        这里的触发条件机制可以修改，例如:save 60  100:60秒内修改了100次key触发RDB

 触发RDB的方式:将redis内存中的输入写入RDB文件

        1、save规则满足的情况下，会自动触发rdb规则

        2、执行flushall命令，也会触发rdb规则

        3、退出redis，也会产生rdb文件

恢复RDB文件:将RDB文件数据写入内存

        只需要将rdb文件放在我们redis启动目录即可，redis启动是会自动检查dump.rdb恢复其中的数据。rdb文件默认是放在安装目录的。

3、优点和缺点

优点:

        1、适合大规模的数据恢复

        2、对数据完整性和一致性要求不高时使用

缺点：

        1、在一定间隔时间做一次备份，所以如果redis意外宕机了，就会丢失最后一次快照后的所有修改

        2、Fork的时候，内存中的数据被克隆了一份，占用了内存空间。

二、AOF方式持久化

1、什么是AOF

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

        Aof保存的是 appendonly.aof 文件

2、配置AOF

        在redis.conf中配置，默认是不开启的

AOF文件数据恢复:数据写入到内存中

正常恢复：

        1、启动：设置Yes，修改默认的appendonly no，改为yes

        2、将有数据的aof文件复制一份保存到对应目录（config get dir）

        3、恢复：重启redis然后重新加载

异常恢复： aof文件被修改，无法启动redis，需要先修复aof文件

        1、启动：设置Yes 故意破坏 appendonly.aof 文件！

        2、修复： redis-check-aof --fix appendonly.aof 进行修复

        3、恢复：重启 redis 然后重新加载

3、优点和缺点

apendfsync everysec

# appendfsync aof持久化策略的配置

# no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。

# always表示每次写入都执行fsync，以保证数据同步到磁盘，消耗性能

# everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。

优点:

        1、每修改同步：appendfsync always 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差 但数据完整性比较好

        2、每秒同步： appendfsync everysec 异步操作，每秒记录 ，如果一秒内宕机，有数据丢失

        3、不同步： appendfsync no 从不同步

缺点:

        1、相同数据集的数据而言，aof 文件要远大于 rdb文件，恢复速度慢于 rdb。

        2、Aof 运行效率要慢于 rdb，每秒同步策略效率较好，不同步效率和rdb相同。

三、总结

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

2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始 的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重 写，使得AOF文件的体积不至于过大。

3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化

4、同时开启两种持久化方式

        在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF 文件保存的数据集要比RDB文件保存的数据集要完整。

        RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者 建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有 AOF可能潜在的Bug，留着作为一个万一的手段。

5、性能建议

        因为RDB文件只用作后备用途，建议只在Slave(从机)上持久化RDB文件，而且只要15分钟备份一次就够 了，只保留 save 900 1 这条规则。

        如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自 己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产 生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite 的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重 写可以改到适当的数值。

        如果不Enable AOF ，仅靠 Master-Slave Repllcation(主从复制) 实现高可用性也可以，能省掉一大笔IO，也 减少了rewrite(重写)时带来的系统波动。代价是如果Master/Slave（例如:主机和从机同时断电） 同时倒掉，会丢失十几分钟的数据， 启动脚本也要比较两个 Master/Slave(中的 RDB文件，载入较新的那个，微博就是这种架构。