文章目录
Redis持久化方式(RDB,AOF)
我们知道，Redis是支持持久化操作的，持久化操作分为RDB(Redis DataBase)和AOF(Append of File)
RDB持久化
通过RDB的全称，我们就能够知道这种方式是redis主要的持久化方式。
RDB理解
- 在指定的时间间隔内将内存中的数据集快照写入磁盘。
- 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
备份过程
- Redis会单独创建（fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
- 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
写时复制机制：需要写的时候再复制
RDB文件位置
在redis.conf中配置文件名称，默认是dump.rdb,
这个文件在redis启动时命令行所在的目录下。
RDB的保存策略
也是配置在redis.conf文件中。
上面save 900 1表示在900秒内，至少有1个key发生改变，则将当前快照保存到rdb文件中。
save 300 10表示在300秒内，至少有10个key发生改变，则将当前快照保存到rdb文件中。
save 60 10000,表示在60秒内，至少有10000个key发生改变。则将当前快照保存到rbd文件中。
当Redis正常退出时，也会触发RDB持久化。
RDB的优缺点
优点：
- 节省磁盘空间(相较于AOF)，因为它存储数据的rdb文件是压缩过的。
- 恢复速度快。
缺点： - redis在fork时使用了写时拷贝技术，但是如果数据庞大时比较消耗性能。
- 备份周期在一定时间间隔做一次备份，在这个周期中如果以外Down掉，则会丢失最后一次快照后的所有修改。
其他常用操作
RDB的备份与恢复
备份
恢复
AOF持久化
通过AOF的全称(append of File)，我们大概知道AOF是通过对文件进行追加的方式记录数据的。
AOF默认不开启
如何开启？也是通过redis.conf配置文件。
配置AOF的文件名
注意：在AOF和RDB同时开启的情况下，AOF生效
如何持久化的
每次我们使用了写操作，Redis的AOF机制都会将操作指令追加在AOF文件中，所以AOF文件保存的是指令。
何时同步数据
依旧在redis.conf文件中配置
如上，默认是每秒同步一次；也可以每次写操作都同步；也可以不主动同步，交给操作系统
问题：如果一直追加文件，文件是不是会越来越大呢？怎么解决？
Redis采用重写机制，超过阈值(配置文件配置)就会激活重写。
注意： 重写并不会在源文件上操作，而是根据数据库已有的数据进行指令编写，生成临时文件，在rename覆盖原旧AOF文件。
如上图，当达到原来的两倍或者大于64mb就会对AOF进行重写。
如何重写？
举个简单的例子
127.0.0.1:6379>set a 123
127.0.0.1:6379>set a 132
那么就会重写为
127.0.0.1:6379>set a 132
AOF比较坑的地方：
如果我们执行了诸如flushdb等操作，这个指令也会记录在AOF文件中，下次恢复时依旧会执行这个指令，所以要打开AOF文件查看是否有此类操作。
AOF的优缺点
优点：
- 备份机制更稳健，丢失数据概率低。
- 可读日志文本(RDB文件被压缩，我们看不懂)，通过操作AOF文件，可以处理误操作。
缺点：
- 比RDB文件更占空间。
- 备份速度慢，因为要执行AOF中全部的指令。
- 每次读写都同步的话，有一定性能压力。
- 存在个别BUG，造成恢复不能。
AOF和RDB用谁？
- 官方推荐两个都使用
- 如果数据不敏感，使用RDB
- 不建议单独使用AOF，可能会出现BUG
- 如果只是用redis做纯内存操作，可以都不用