redis持久化

redids持久化

原因：redis基于内存，当发生故障(关机，断电，进程异常退出等)后，内存中数据会丢失，需要将数据持久化到硬盘。
目的：为了故障后将数据加载恢复到内存。
方式：redis提供了两种持久化的方式，RDB(快照存储)，AOF(Append only file)。其中RDB是默认的持久化方式。

RDB

方式：快照存储，周期性的将数据快照并保存到硬盘
配置：可以在配置文件中配置存储周期

save 900 1 #900秒内至少有1个key被更改就执行快照
save 300 10 #300内描述至少有10个key被更改就执行快照
save 60 10000 #60秒内至少有10000个key被更改就执行快照

保存有两种方式，一种是save，一种是bgsave，bgsave不会阻塞redis主进程的数据读写操作。
redis自动调用是使用bgsave进行存储，即不会阻塞redis主进程的存储操作。

优点

RDB文件是一个二进制文件，他的编码和redis数据在内存中的编码格式是一致的，所以恢复速度远快于AOF

缺点

因为不是实时存储，所以RDB方式在故障后会丢失最后一次持久化后更新的数据，无法保证实时一致性。

AOF

方式：不同于RDB， AOF是把写命令追加到aof文件中，当数据恢复时，redis会重新执行aof中的全部命令。
配置：默认情况下，redis没有开启AOF持久化，aof有三种方式

appendonly yes #启用aof持久化
appendfsync everysec #每秒钟强制写入磁盘一次
#appendfsync always #每收到一条写命令就立即写入磁盘
#appendfsync no #依赖os的写入，一般30秒一次

优点

aof的三种持久化配置，分别均衡了一致性和可用性，其中always保证完全一致性，no一致性较差，everysec是较折中的方案，根据业务需求进行具体选择

缺点

1. 因为aof保存的是命令，所以在数据恢复的时候要进行命令执行，速度较RDB慢
2. 因为aof是不断的追加的写操作，那么对一条数据的多个写操作会存储多条，导致aof文件会越来越大，但是redis提供了aof文件重构的方法，即根据redis库重构aof文件，减小文件大小。

重写aof文件的配置

no-appendfsync-on-rewrite yes #当aof文件重写时，将之后到来的写命令暂时存放在缓存中。
auto-aof-rewrite-percentage 100 #当前文件大小是上次重写后文件大小的两倍时，启动重写。
auto-aof-rewrite-min-size 64mb #当aof文件小于64mb时不会进行重写。

选择

RDB可以提供更快的数据恢复速度，AOF可以提供更强的一致性，当然可以同时配置RDB和AOF，但是同时配置了RDB和AOF时，redis数据恢复时会优先使用AOF。

主从复制时

主从第一次同步时，Master会dump RDB文件，先将RDB同步给Slave用于数据初始化，之后会把dump之后到达的写命令转发给Slave。
如果主从连接出现问题，那么连接恢复后，Master仍然会重复上述过程，从同步 dmup RDB开始。