以下都是干货，请认真看！

redis持久化方式：
RDB (Redis DB) 类似于hdfs中的fsimage 快照方式
AOF（AppendOnlyFile）类似于hdfs中的edit logs。默认是关闭的

以上两种持久化方式,恢复数据时如果两个都开启只有AOF生效。

快照方式的持久化：从内存到磁盘IO操作，所以不可能每时每秒都发生。时点式或间隔性的磁盘IO。

AOF方式的持久化：将增删改命令以线性追加文件的方式，追加到存储文件中。

以下分别具体阐述：

RDB 在默认情况下，Redis将数据库快照保存在名字为dump.rdb的二进制文件中。

产生RDB的方式：
1） 阻塞方式：客户端中执行save命令 （redis服务端会暂时停止对外提供服务，只执行save命令）
2） 非阻塞方式：bgsave （redis主进程依然提供对外服务，fork一个子进程进地bgsave命令）

实现策略

1）自动：按照配置文件中的条件满足就执行bgsave
如：save 60 1000, redis要满足在60秒内至少有1000个键被改动，会自动保存一次。

2）手动：客户端发起save,bgsave命令。

AOF Append only file,采用追加的方式保存。默认文件appendonly.aof。记录所有的写操作命令，在服务启动的时候使用这些命令就可以还原数据库。

AOF写入机制
1）AOF方式不能保证绝对不丢失数据
2）目前常见的操作系统中，执行系统调用write函数，将一些内容写入到某个文件里时，为了提高效率，系统通常不会直接将内容写入硬盘里面，而是先将内容放入一个内存缓冲区(buffer)里面，等到缓冲区被填满，或者用户执行fsync调用和fdatasync调用时才将储存在缓冲区里的内容真正的写入到硬盘里，未写入磁盘之前，数据可能会丢失。

写入磁盘的策略

appendfsync选项，这个选项的值可以是always、everysec或者no

Always:服务器每写入一个命令，就调用一次fdatasync,将缓冲区里面的命令写入到磁盘。这种情况下服务器出现故障也不会丢失任何已经成功执行的命令数据。

everysec:服务器每一秒钟调用一次fdatasync，将缓冲区里面的命令写入到磁盘，这种模式下服务器出现故障，最多只丢 失一秒钟内的执行命令数据。

NO:服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到磁盘。这种模式下服务器遭遇意外停机时，丢失命令的数量是不确定的。

问题：服务器开机时间长，操作多，AOF文件会很大，怎么办？

AOF重写机制，解决文件大的问题。抵消或去掉重复命令。

AOF重写触发
手动：客户端向服务器发送gbrewriteaof命令。
自动：配置文件中的选项，自动执行bgrewriteaof命令

auto-aof-rewrite-min-size <size> 触发AOF重写所需的最小体积：只要在AOF文件的体积大于等于size时，才会考虑是否需要进行AOF重写，这个选项用于避免对体积过小的AOF文件进行重写。

auto-aof-rewrite-percentage <percent> 指定触发重写所需要的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积，并且超过上一次重写之后的AOF文件的体积的percent%时,就会触发AOF重写（如果服务器刚刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值）。将这个值设置为0表示关闭自动AOF重写

例: auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
appendonly yes

当AOF文件增量大于超始的size（64mb）的100%时(就是文件大小翻倍)，启动重写

AOF优点：
1）写入机制，默认fysnc每秒执行，性能很好不阻塞服务，最多丢失一秒的数据。
2）重写机制，优化AOF文件。
3）如果误操作(如：flushall)，只要aof未被重写，停止服务移除AOF文件尾部的FLUSHALL命令，重启redis，可以将数据集恢复到FLUSHALL执行之前的状态。
缺点：
1）相同数据集,aof文件体积较RDB大了很多
2）恢复数据库速度比RDB慢。