开门见山,redis的持久化方式共两种 RDB和AOF
1.RDB
RDB 即snapshoting,我理解就是Repeat-Database(个人理解)。这是一种将内存中数据通过dump文件转储到磁盘的方式,即每次快照都会获得当前数据的一次完整快照,并以dump文件存在电脑的磁盘中。每次快照开始,redis都会folk(),即启动一个完全相同的子进程进行快照的工作,而父进程只需要完成redis当前redis的正常功能,并不会进行IO等操作,所以对客户可以做到无感知,这也是REDIS速度快的一个原因
For example, this configuration will make Redis automatically dump the dataset to disk every 60 seconds if at least 1000 keys changed:
save 60 1000
看,就是这么用的。redis官方指导
2.AOF
AOF 即apend-onlyFile, 这个AOF的原理也很简单,就是在后台记录日志,记录什么日志呢,比如redis现在set name0 "zhangsan",那么后台日志文件就会记录一条这样的命令。所以AOF的F就是这个日志文件,显而易见,AOF比RDB慢的原因之一就是AOF是记录的命令,而RDB直接拷贝的数据。
我们试想一个场景,redis中的一个key被重新命名了100次才得到最终的值,那后台也就是有这样100条命令,显而易见,前99条命令都是没用的。想到这里我们就想到AOF的一个问题,随着redis的命令越来越多,这命令文件不是越来越大么,这咋办呢,联系之前的场景,reidis有个日志重写的机制,就是当前日志进行重写,如果你用的是2.4之前的版本,那就要运行BGREWRITEAOF 命令强制进行日志重写,到了2.4就可以自动触发了。怎么重写呢,跟RDB一样,先folk(),然后子进程就会对之前的日志文件进行重写,把之前多条命令修改同一个key的命令改为最有效最少的命令,而父进程会仍然把新的命令不断加到旧的文件中,同时还会把这些新加入的命令在多写一份临时的。这样保证了即使日志重写的子进程出现了问题AOF仍然是安全的,当然在绝大部分情况下,AOF都是不会出问题的,在子进程对日志重写开始时间点时的日志文件重写完毕后,就会将临时文件的命令加入新文件,然后下一次日志记录就在新的日志中继续进行。
AOF 的 fsync 默认有三种配置方式
1.always 每次redis有新命令,就fsync
2.everysec 每秒
3. never从不
这三种,第二种是redis默认的方式,第一种very very slow ,very safe 即使断电或者日志写入磁盘满了或者redis的服务器宕机了
最后一行命令也可以通过redis的修复命令进行修复,第二种会失去最后一秒写入的数据
3.对比
对RDB和AOF介绍完后,根据他俩的机制,他俩的优缺点有哪些。
1.RDB可以控制fsync的频率,显而易见,RDB更快,当然如果RDB fsync设置成一秒的那么就一样快(但这样做的话RDB会更慢,况且这样的话为啥还要用RDB呢哈哈)。这个快指的是程序运行中的快。RDB还有另一种快,就是恢复数据库时的快,比起执行一行行的命令,直接获得数据显然更快一些,因为省去了解析命令的时间,所以对于数据量特别大的数据库恢复,RDB比AOF更适合。如果对某一时间后的数据不是特别重视,那RDB策略就更适合于AOF,而RDB所产生的单一文件(通常比AOF产生的日志文件小很多)更适合于网络传输,所以更适用于容灾。
2.AOF的虽然缺点明显,优点也相当明显,那就是在断电情况或者服务器宕机或者磁盘写满这种极端情况下,AOF可以保证更全面的数据恢复,可以对大限度保存所有数据,即使是设置1秒fsync,丢失的也仅仅是最后一秒的写入命令数据