redis持久化RDB（数据可能不够完整）和AOF

官方推荐两个都启用。

 

如果对数据不敏感，可以选单独用RDB。

 

不建议单独用 AOF，因为可能会出现Bug。

 

如果只是做纯内存缓存，可以都不用。

同时开启RDB和AOF，系统默认取AOF保存下来的数据（数据不会丢失）

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？

建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

RDB:修改/etc下的redis.conf 

save 30 5

AOF:将/etc/redis.conf中的appendonly改为yes

appendonly yes

性能建议：

RDB：因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则

AOF：只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

修改/etc/redis.conf（auto-aof-rewrite-percentage：文件达到100%时开始重写          auto-aof-rewrite-min-size：最开始达到最小文件64MB值开始重写。）       

auto-aof-rewrite-percentage 100          auto-aof-rewrite-min-size 64mb

RDB：在指定的时间间隔中将内存中的数据集快照（关于指定数据集合的一个完全可用拷贝，该拷贝包括相应数据在某个时间点（拷贝开始的时间点）的映像）写入磁盘中。

恢复是将快照文件读取到内存中。

优势：

适合大规模的数据恢复

对数据完整性和一致性要求不高更适合使用

节省磁盘空间

恢复速度快

劣势：

Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

修改/etc下的redis.conf（30秒中如果有5个key改变就进行持久化操作，将数据集存入redis目录中的dump.rdb文件中（也可以修改路径和文件名））

达到阈值才会将阈值之内的数持久化（例如修改8个key，只有5个key会持久化）

# save 3600 1
# save 300 100
# save 60 10000
save 30 5

备份数据集为dump.rdb.bak

cp dump.rdb dump.rdb.bak

删除了原本数据集

rm -rf dump.rdb

在数据集丢失情况将备份作为主数据集（改名）

mv dump.rdb.bak dump.rdb

Redis 会单独创建( fork )一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，

且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。（在redis挂掉后数据会丢失，存入不了）

AOF：以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，

redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

优势

备份机制更稳健，丢失数据概率更低。

可读的日志文本，通过操作AOF稳健，可以处理误操作。

劣势

比起RDB占用更多的磁盘空间。

恢复备份速度要慢。

每次读写都同步的话，有一定的性能压力。

存在个别Bug，造成恢复不能。

将/etc/redis.conf中的appendonly改为yes

appendonly yes

esc  :wq

可以通过命令ll（LL）查看文件详情发现aof新创建了一个存储文件appendonly.aof

ll

当appendonly.aof其中的内容出错时，启动不了redis，会显示连接失败，可以修复appendonly.aof文件

redis-check-aof --fix appendonly.aof

Rewrite压缩（重写）

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，

Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB

重写流程与RDB中fork的操作一致

AOF同步频率设置

appendfsync always

始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

redis不主动进行同步，把同步时机交给操作系统。