彻底理解Redis持久化( 二 ) _Redis持久化

2. 旧AOF文件含有的无效命令 del k1, set a 1, set a 2 。重写使用进程内的数据直接生成， aof文件就保留最新的命令集合。
3. 多条命令可以合并为一个命令，为了防止单个命令过大造成客户端缓冲区溢出，对于list,set,hash,zset 等类型的操作，以64个元素为界拆分为多条。
触发机制

文章插图

1. 手动触发执行bgrewriteaof命令。
2. 根据配置自动触发
auto-aof-rewrite-min-size 表示运行AOF重写是文件最小的大小。默认64M ，小于64M就会不自动重写了。
auto-aof-rewrite-percentage 表示（ aof_current_size - aof_base_size ） / aof_base_size 的比值。
aof文件重写之后当前文件大小增长多少就触发重写自动触发时机 :

aof_current_size > auto-aof-rewrite-min-size

&&

( aof_current_size - aof_base_size ) / aof_base_size >= auto-aof-rewrite-percent

age

三 RDB VS AOF 对比具体使用哪种持久化方式，下面是来自官方的建议：
通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB 。很多用户仅使用了AOF ，但是我们建议，既然RDB可以时不时的给数据做个完整的快照，并且提供更快的重启，所以最好还是也使用RDB 。
生产上的实例大多不会是单点，而是主从，也有利用slave作为持久化方式，同时满足HA的需求。读者朋友可以分享一下各自遇到的和 redis 持久化相关的问题。