稚久|java：Redis持久化( 二 ) 2.1介绍

#AOF的优点：1.AOF可以更好的保护数据不丢失，一般AOF会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失1秒的数据。 2.AOF以appen-only的模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。 3.AOF日志文件的命令通过非常可读的方式进行记录，这个非常适合做灾难性的误删除紧急恢复，如果某人不小心用flushall命令清空了所有数据，只要这个时候还没有执行rewrite ，那么就可以将日志文件中的flushall删除，进行恢复。 #AOF的缺点1.对于同一份文件AOF文件比RDB数据快照要大。 2.AOF开启后支持写的QPS会比RDB支持的写的QPS低，因为AOF一般会配置成每秒fsync操作，每秒的fsync操作还是很高的3.数据恢复比较慢，不适合做冷备。四.补充说明4.1RDB和AOF选择
不要仅仅使用RDB这样会丢失很多数据。也不要仅仅使用AOF ，因为这样会有两个问题，第一通过AOF做冷备没有RDB做冷备恢复的速度快；第二RDB每次简单粗暴生成数据快照，更加健壮。综合AOF和RDB两种持久化方式，用AOF来保证数据不丢失，作为恢复数据的第一选择；用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，可以使用RDB进行快速的数据恢复。
4.2.1介绍
?为了解决AOF文件体积膨胀的问题， Redis提供了AOF重写功能：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。
?AOF重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有AOF文件进行任何分析操作。
4.2.2AOF重写触发的方式
a.手动触发：用户通过调用bgrewriteaof手动触发
b.自动触发：如果全部满足的话，就触发自动的AOF重写操作：
?没有RDB持久化/AOF持久化在执行，没有bgrewriteaof在进行；?当前AOF文件大小要大于redis.conf配置的auto-aof-rewrite-min-size大小；?当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比（在配置文件设置了auto-aof-rewrite-percentage参数，不设置默认为100%）【稚久|java：Redis持久化】?#redis.conf配置文件中的相关设置auto-aof-rewrite-percentage100?#大于原来的100%就自动重写auto-aof-rewrite-min-size64m?#自动重写的最小尺寸