jinfeng_wang

Redis是一个支持持久化的内存数据库，通过持久化机制把内存中的数据同步到硬盘文件来保证数据持久化。当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据的目的。

RDB

RDB是Redis默认的持久化方式。按照一定的时间周期策略把内存的数据以快照的形式保存到硬盘的二进制文件。即Snapshot快照存储，对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。

# 快照的文件名
dbfilename dump.rdb
# 存放快照的目录
dir /var/lib/redis
# 在进行镜像备份时,是否进行压缩。
# yes：压缩，但是需要一些cpu的消耗。
# no：不压缩，需要更多的磁盘空间。
rdbcompression yes
#900秒后且至少1个key发生变化时创建快照  
save 900 1 
#300秒后且至少10个key发生变化时创建快照  
save 300 10 
#60秒后且至少10000个key发生变化时创建快照  
save 60 10000 

一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。例如，每隔5分钟或者更长的时间来创建一次快照，Redis停止工作时（例如意外断电）就可能丢失最近几分钟的数据。

AOF

Redis会将每一个收到的写命令都通过Write函数追加到文件最后，类似于MySQL的binlog。当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

# 是否开启AOF，默认关闭（no）
appendonly yes

由于Linux会把对文件的写入操作通过buffer缓冲，因此Linux可能不是立即写入到文件，有对视数据的风险。Redis有三种不同的fsync策略供选择：no fsync at all、 fsync every second、 fsync at every query。默认为fsync every second此时的写性能仍然很好，且最坏的情况下可能丢失一秒钟的写操作。

# Redis支持三种不同的刷写模式：
#每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
# appendfsync always 
#每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
appendfsync everysec
#完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。
# appendfsync no  

AOF带来了另一个问题，持久化文件会变得越来越大。比如，我们调用INCR test命令100次，文件中就必须保存全部的100条命令，但其实99条都是多余的。因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。为了合并重写AOF的持久化文件，Redis提供了bgrewriteaof命令。收到此命令后，Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件，以此来实现控制AOF文件的合并重写。由于是模拟快照的过程，因此在重写AOF文件时并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。

# AOF文件名  
appendfilename appendonly.aof 
#当进程中BGSAVE或BGREWRITEAOF命令正在执行时不阻止主进程中的fsync()调用（默认为no，当存在延迟问题时需调整为yes）  
no-appendfsync-on-rewrite no 
#当AOF增长率为100%且达到了64mb时开始自动重写AOF  
auto-aof-rewrite-percentage 100 
auto-aof-rewrite-min-size 64mb