redis的持久化

1、什么是redis的持久化

用来将redis存储的数据写入磁盘，方式数据丢失。通俗的讲假如没有执行持久化，那么redis关闭之后我们所写的数据将会全部丢失。持久化之后，当我们每次启动redis时，他会自动读取本地磁盘的持久化文件，将数据取出放入 。

持久化的两种方式

（1）RDB

1、RDB的原理

1>在某个时刻redist通过fork产生子进程，和一个父进程的快照，其中有和父进程相同的数据。
2>子进程负责将快照写入零时文件。
3>子进程写完后，用临时文件替换原来的快照文件，然后子进程退出。

配置

** 00件名**

stop-writes-on-bgsave-error yes #快照失败后是否继续写操作

rdbcompression yes #是否压缩快照文件

细节

1> 如果发生系统崩溃，则会丢失最近一次rdb之后的数据，所以如果项目不能接受这样的数据损失,还需要其他安全手段

2> 不适于实时性持久化，但其数据体量小，执行速度快，适合做数据版本控制

3> 如果数据量巨大，则创建子进程的时间长，导致redis卡顿，要谨慎设置save参数时间间隔大一些；

​ 或如果软件允许，可以每天在闲时手动同步（凌晨后…）

4> 将生成的快照文件，留在原地，则可以在重启redis后，保持数据状态

​ 将生产的快照文件，复制到其他redis服务中，可以方便的将数据移植过去

触发方式

1> 某一个save参数被满足

2> 执行 bgsave

3> 执行 save

4> redis服务关闭时

(2) AOF

原理

1> Redis将每一个写操作(执行成功)，写入一个aof文件，

2> Redis重启时只要从头到尾执行一次aof文件，即可恢复据；

​ 也可以将aof文件复制到别的服务器，做数据移植

注意：在重启时，要恢复数据，如果rdb文件和aof文件同时存在，以AOF为准

配置

appendonly yes # 启动AOF机制

appendfsync always # 每次收到写命令就立即强制 写入磁盘，保证完全的持久化，但产生极大的IO开销(不推荐使用)

appendfsync everysec # 每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中(推荐使用）

appendfsync no # 由操作系统决定何时同步，如果系统宕机则导致redis丢失不定数量数据

appendfilename “appendonly.aof” #设置aof文件名

细节

1> AOF文件会不断增长(可能比快照文件大几倍)，在极端情况下，可能会对硬盘空间造成压力

2> Redis重启时，需要重新执行一个可能非常大的AOF，时间会很长

3> AOF同步时间间隔小，数据更安全，理论上至多丢失1秒的数据，比rdb更擅长做更实时的持久化

AOF重写

原理

为了减小aof文件的体量，可以手动发送 bgrewriteaof 命令，则会创建子进程，生成更小体量的aof，然后替换掉旧的、大体量的aof文件。

配置

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

在体量超过64mb，且比上次重写后的体量增加了100%时自动触发重写

细节

1> 如果当前数据量巨大，则子进程创建过程会很耗时

2> 在替换aof文件时，如果旧aof很大，则删除它也是一个耗时的过程