Redis持久化两种方式

RDB持久化

RDB 是以二进制文件，是在某个时间点将数据写入一个临时文件

优点：使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能
缺点：RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

RDB 默认开启，redis.conf 中的具体配置参数如下：

#dbfilename：持久化数据存储在本地的文件
dbfilename dump.rdb
#dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下
dir ./
##snapshot触发的时机，save    
##如下为900秒后，至少有一个变更操作，才会snapshot  
##对于此值的设置，需要谨慎，评估系统的变更操作密集程度  
##可以通过“save “””来关闭snapshot功能  
#save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key300s进行存储；更改10000个key60s进行存储。
save 900 1
save 300 10
save 60 10000
##当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等  
stop-writes-on-bgsave-error yes  
##是否启用rdb文件压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间  
rdbcompression yes  

1、手动执行

（1）save指令 

手动执行rdb持久化。

注意：save指令保存的数据量很大，会阻塞redis服务器（因为redis执行指令是单线程的），直到他执行完毕，因此不建议在线上环境用save指令。

（2）bgsave指令

手动执行rdb持久化（利用linux的fork函数，后台新增子进程去执行，不影响主进程）。

2、自动执行

设置配置文件 save second changes

参数说明：second：监控时间范围，changes：监控key的变化量

例如：save 900 1，表示更改了一个key的值间隔900s持久化一次。使用的是bgsave来持久化。

AOF持久化

Append-only file，以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令 达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化。目前已经是Redis持久化的主流方式。

优点：可以保持更高的数据完整性，如果设置追加 file 的时间是 1s，如果 redis 发生故障，最多会丢失 1s 的数据；且如果日志写入不完整支持 redis-check-aof 来进行日志修复；AOF 文件没被 rewrite 之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）。
缺点：AOF 文件比 RDB 文件大，且恢复速度慢。

AOF 默认关闭，开启方法，修改配置文件 reds.conf：appendonly yes

appendfsync always|everysec|no —— AOF写数据三种策略(appendfsync)

• always(每次）：每次写入操作均同步到AOF文件中数据零误差，性能较低，不建议使用。

• everysec（每秒）：每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据 数据准确性较高，性能较高，建议使用，也是默认配置

• no（系统控制）：由操作系统控制每次同步到AOF文件的周期，整体过程不可控

 什么叫AOF重写？

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

例如：连续执行 set key 111、set key 222 ，只会记录set key 222

如何自动重写？