Redis持久化
Redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会消失。所
以Redis提供了持久化功能!
什么是RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
Redis会单独创建( fork )一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文
件替换上次持久化好的文件。整个过程中,主进程是不进行任何I0操作的。这就确保了极高的性能。如果需要进行大规模数据的恢
复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢
失。
默认就是RDB,一般不需要修改配置
rdb保存的文件是dump.rdb都是在我们的配置文件中快照中进行配置的!
rdb触发机制
- 配置文件中的save保存时间和执行次数
**优点: **
-
适合大规模的数据恢复!
-
对数据的完整性要不高!
缺点:
-
需要一定的时间间隔进程操作!如果redis意外宕机了,这个最后一次修改数据就没有的了!
-
fork进程的时候,会占用一定的内容空间! !
AOF(Append Only File)
将我们的所有命令都记录下来, history ,恢复的时候就把这个文件全部在执行一遍!
什么是AOF
以日志的形式来记录每个写操作, 将Redis执行过的所有指令记录下来(读操作不记录) , 只许追加文件但不可以改写文件, redis
启动之初会读取该文件重新构建数据,换言之, redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复
工作
默认是不开启的,我们需要手动进行配置!我们只需要将appendonly改为yes就开启了aof !
重启, redis就可以生效了!
如果这个aof文件有错位,这时候redis 是启动不起来的吗,我们需要修复这个aof文件
redis给我们提供了一个工具 redis-check-aof --fix(被修复的那一条写操作也会丢失)
appendonly no #默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用!
appendfilename "appendonly.aof" #持久化的文件的名字
# appendfsync always #每次修改都会sync。 消耗性能
appendfsync everysec #每秒执行一次sync, 可能会丢失这1s的数据!
# appendfsync no #不执行sync, 这个时候操作系统自己同步数据，速度最快!
如果aof文件大于64m,太大了! fork一个新的进程来将我们的文件进行重写!
重写就是把能合并的命令合并，比如多次操作一个key，就可以合并成一个，无效的key的操作就可以全部删除。
优点和缺点
优点:
- 每一次修改都同步,文件的完整会更加好!
- 每秒同步一次,可能会丢失一秒的数据
- 从不同步,效率最高的!
缺点:
- 相对于数据文件来说, aof远远大于rdb ,修复的速度也比rdb慢!
- Aof 运行效率也要比rdb慢,所以我们redis默认的配置就是rdb持久化!
来源于：【狂神说Java】Redis最新超详细版教程通俗易懂