Redis的持久化方式

开门见山，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,丢失的也仅仅是最后一秒的写入命令数据

但是官方还是建议两种策略一起用，毕竟双保险。还有一个将两种策略合成一种的长远计划

欢迎交流指正