redis学习3--持久化

reids实现持久化的两种方式:rdb和aof

1.rdb

rdb:redis database,是指在指定的时间间隔内（比如：1分钟为一个间隔），将内存中的数据集快照直接写到磁盘，也就是snapshot快照（个人理解：一段段的数据保存到内存），它恢复时是将快照文件直接读取到内存。
Reids会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不会进行任何IO操作的，这就确保了极高的性能。如果需要大规模的数据恢复，且对于数据恢复的完整性不是非常敏感，那rdb方式要比aof方式更加的高效。Rdb的缺点是最后一次持久化的数据可能会丢失。（个人理解：比如最后60s没结束就进行持久化了，那这一个时间段的数据就会丢失）。
fork：复制一个与当前进程一样的进程。新的进程的所有的数据（变量，环境变量，程序设计器等）都和原进程一致。但是它是一个全新的进程，并作为原进程的子进程。
rdb保存的文件名：dump.rdb
保存策略（快照）：可以在redis.conf的文件中查看，命令是： save 秒数 变化数。一般有3中策略：save 900 1在900秒内有一条数据变化就保存到dump.rdb；一种是save 300 10；最后一种是save 60 10000。当然也可以禁用保存策略，它会即刻备份。（注意：Save或者bagesave也会立刻执行快照，flushall也会）
小问题：如果执行flushall后关机，在启动redis原来的key会不会存在？
答案：不会，因为执行dump.rdb文件的时候，它同样会执行dump.rdb文件中flushall命令，因此解决办法是：复制备份好的dump.rdb（前提是备份有~~）
优势：适合大规模的数据恢复，对数据完整性和一致性要求不高。
劣势：可能会丢失最后一次快照的修改内容；而且fork的时候内存中的数据被克隆了一份，大致两倍的膨胀要考虑。

2.aof

aof可以解决由于rdb最后一次备份数据丢失的问题。
aof（append only file）原理：以日志的形式记录每一个写操作，将redis的所有写指令记录下来（只记录写，不记录读），并将写记录日志追加到文件的结尾，redis启动的时候会读取文件并重新构建数据，也就是说redis重启的时候会根据文件的内容将所有的写指定从头到尾又执行一遍。
aof保存的文件名：appendonly.aof
注意：如果rdb和aof同时启动，它会优先启用aof。如果appendonly.aof损坏可通过命令：redis-check-aof –fix appendonly.aof 修复，同理dump.rdb也可用类似的指令修复。
Redis中开启和关闭aof(修改redis.conf)：appendonly yes —- 打开aof，同时将快照功能置于低优先级的位置
appendfsync no
**文件同步策略：**1.always:同步持久化，每次数据变更就会立即记录到磁盘（数据完整性最好）
2.Everysec:出厂默认设置，一秒同步一次，存在问题是如果一秒内宕机就会数据丢失
3.no:不同步
重写：对appendonly.aof进行压缩，只保留可以恢复数据的最小指令。触发机制：当aof文件达到预先设定的值的大小时触发，而且新的文件大小默认是原来的一倍（redis.conf文件中有默认大小）
和rdb的比较：相同数据集的数据而言aof文件要远大于rdb文件，恢复速率慢于rdb，但每秒同步效率好。

3.笔记来源

看某培训机构的redis培训视频，根据自己的理解记录