PIPIONE
RDB的问题1:fork一个进程时,内存的数据也被复制了,即内存会是原来的两倍2:每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步脏数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘io操作,可能会严重影响性能。3:由于快照方式是在一定间隔时间做一次的,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改。触发快照的情况1:根据配置规则进行自动快照2:用户执行save或bgsave命令3:执行flushall命令4:执行复制replication时save命令执行Save命令时,Redis会阻塞所有客户端的请求,然后同步进行快照操作。bgsave命令执行bgsave命令时,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。flushall命令这个命令会导致redis清除内存中的所有数据,如果定义了自动快照的条件,那么无论是否满足条件,都会进行一次快照操作;如果没有定义自动快照的条件,那么就不执 行快照AOF的问题默认的AOF持久化策略是每秒钟fsync一次,fsync是指把缓存中的写指令记录到磁盘中,在这种情况下,redis扔可以保持很高的性能当然由于OS会在内核中缓存write做的修改,所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过可以通过配置文件告诉redis,想要通过fsync函数强制os写入磁盘的时机AOF方式在同等数据规模的情况下,AOF文件要比RDB文件的体积大,因此AOF方式的恢复速度也要慢于RDB方式AOF日志恢复如果在追加日志时,恰好遇到磁盘空间满或断电等情况,导致日志写入不完整,也没有关系,redis提供了redis-check-aof工具,可以用来进行日志修复,基本步骤如下:1、备份被写坏的AOF文件2、运行redis-check-aof -fix进行修复3、用diff -u来看下两个文件的差异,确认问题点4、重启redis,加载修复后的AOF文件AOF重写AOF采用文件追加方式,这样会导致AOF文件越来越大,为此,redis提供了AOF文件重写(rewrite)机制,即当AOF文件的大小超过所设定的阈(yu)值时,redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof. 本回答由网友推荐