###
一、Redis的持久化介绍
Redis相比Memcache有个最显著的区别就是支持数据持久化，可以将数据写入到硬盘中，而不仅仅是只能存放于内存，重启服务后数据就没了。Redis的持久化分为了rdb快照持久化和aof日志持久化两种方式： 1、RDB快照持久化：每隔一段时间或者操作次数达到一定量后，从内存Dump数据形成rdb文件，RDB文件是经过压缩的二进制数据，文件会比较小，恢复速度快。RDB持久化的缺点是有可能导致一部分数据遗失 2、AOF日志持久化：类似MySQL的Binlog，可以实现每次操作的持久化，数据最为安全，但是影响性能。这两种方式一般会同时配置。建议在从库上执行数据的持久化，减少对主库性能的影响。
二、手动保存Redis数据
在配置RDB和AOF前还需要了解下保存Redis数据的命令——save和bgsave，在生产环境中建议使用bgsave进行保存数据，它会fork出一个子进程来读取内存中的数据并写入到文件中，除了fork期间会有短
暂的阻塞，后续的操作都不会阻塞客户端的读写请求。但是由于fork出来了新进程，在保存数据的时候内存的消耗也会double，要小心OOM风险。
三、RDB持久化配置方法
编辑redis.conf配置文件，主要修改以下内容： save 900 1 #在900秒内，key值发生变化次数超过1次则进行持久化，生产环境通常默认这个值即可 save 300 10 #在300秒内，key值发生变化次数超过10次则进行持久化，生产环境通常默认这个值即可 save 60 10000 #在60秒内，key值发生变化次数超过10000次则进行持久化，生产环境通常默认这个值即可 stop-write-on-bgsave-error yes # 如果rdb文件在导出过程中出错则让Redis停止任何写数据请求，避免数据不一致 rdbcompression yes #压缩rdb数据，消耗CPU性能来节约磁盘空间 rdbchecksum yes #服务启动时检查rdb文件的完整性，如果不完整则不启动 dbfilename dump.rdb #rdb文件名 dir /data/redis/rdb/ #rdb文件保存路径，启动时会从该目录寻找rdb文件
当设置完后重启Redis服务，然后在工作中只要达到了save条件，key就会被保存。并且日志中也会有“xx changes in xx seconds. Saving”这样的记录。如果要关闭rdb功能的话将save选项改为save ""，引号里为空即可
四、AOF持久化配置方法
编辑配置文件，修改以下内容： appendonly yes #打开aof功能 #appendfsync no #让系统决定持久化时机，Linux默认30秒写入一次数据到磁盘 #appendfsync always #每个命令都写入磁盘，最多丢失一条命令的数据 appendfsync everysec #每秒写一次数据到磁盘，最多丢失一秒数据，满足大部分应用场景，推荐使用 no-appendfsync-on-rewrite yes #如果正在导出rdb数据，停止aof的写入（aof将保存在一个队列中，rdb备份完成后执行队列，不会丢失数据） auto-aof-rewrite-percentage 100 #aof文件体积与上次相比增长率达到100%就进行重写（重写相当于记总账，比如对同一个key做了100次操作，我们只需要最后一次的操作，重写就会把多余的操作给忽略掉） auto-aof-rewrite-min-size 64m #和上一项组合使用，aof文件达到64M时进行重写（重写会节省掉空间，因为多余的操作被删除了） appendfilename "appendonly.aof" #aof文件名 dir /data/redis6379 当Redis服务启动后需要进行数据恢复时，如果同时开启了rdb和aof持久化，Redis只会加载aof文件（因为aof即时性高于rdb），如果rdb有数据时，再开启aof选项会把已经存储过的数据清空
当AOF写入文件时如果服务器崩溃或AOF存储已满的情况下，最后一条命令可能会被截断并产生异常的AOF文件。在AOF文件异常的情况下，如果Redis配置文件中指定了aof-load-truncated为yes，那么Redis在启动时会忽略最后一
条命令并顺利启动 Redis，否则启动会失败。而如果AOF文件中间命令被破坏的话则需要使用redis-check-aof命令跳转到出现问题的命令行然后尝试手动修复此文件。如果无法手动修复，可以使用redis-check-aof --fix 自动
修复AOF 异常文件，不过可能会导致异常部分至文件末尾的数据全部被丢弃。
文章转自
http://www.linuxe.cn/post-319.html
###