redis持久化策略

redis作为一个支持持久化的内存数据库，常用作cache。

redis持久化方式：1 Snapshotting(快照) 2 Append-only file(aof)

Snapshotting 是默认的持久话方式，此方式是将内存中的数据以快照的方式写入到二进制文件中，默认文件名为dump.rdb。可以通过修改配置文件设置自动快照方式。

Java代码

1. save 900 1 #900秒内如果发生超过一个key被修改，则发起快照保存
2. save 300 10 #300秒内如果发生超过10个key被修改，则发起快照保存
3. save 60 10000 #60秒内如果发生超过10000个key被修改，则发起快照保存

优点：快照易回复，而且文件小

缺点：当redis挂掉后会丢掉最后一次快照到挂掉时的数据

AOF比RDB方式有更好的持久化性。此方式是Redis会将没一个收到的写命令都通过write函数追加到文件中，类似于MySQL中的 binlog。默认写入文件为：appendonly.aof。当redis重启时会通过执行文件中保存的写命令来在内存中重建整个数据库内容。

Java代码

1. appendonly yes #启用AOF持久化方式
2. appendfilename appendonly.aof #AOF文件的名称，默认为appendonly.aof
3. # appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
4. appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
5. # appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。

优点：更好的持久化，redis挂掉后只丢失最后1s的文件

缺点：持久化文件会变的越来越大

对持久化文件越来越大的解决方法：

为了压缩AOF的持久化文件，Redis提供了bgrewriteaof命令。
收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件，以此来实现控制AOF文件的增长。
由于是模拟快照的过程，因此在重写AOF文件时并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件

Java代码

1. no-appendfsync-on-rewrite yes #在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
2. auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
3. auto-aof-rewrite-min-size 64mb #当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

AOF and RDB persistence can be enabled at the same time without problems.

按照我的理解两个可以同时使用。
只是如果有配置AOF，重启时，默认会从aof恢复

这里有个问题，就要大家斟酌了，如果即用了快照也用了追加日志方式，redis是两种策略都使用。但是都用性能方面就要考虑了。建议大家只用AOF方式来处理redis的持久化策略