Redis持久化

Redis 的读写都是在内存中，所以它的性能较高，但在内存中的数据会随着服务器的重启而丢失，为了保证数据不丢失，我们需要将内存中的数据存储到磁盘，以便 Redis 重启时能够从磁盘中恢复原有的数据，而整个过程就叫做 Redis 持久化。

Redis 持久化的几种方式

• 快照方式（RDB, Redis DataBase）将某一个时刻的内存数据，以二进制的方式写入磁盘；
• 文件追加方式（AOF, Append Only File），记录所有的操作命令，并以文本的形式追加到文件中；
• 混合持久化方式，Redis 4.0 之后新增的方式，混合持久化是结合了 RDB 和 AOF 的优点，在写入的时候，先把当前的数据以 RDB 的形式写入文件的开头，再将后续的操作命令以 AOF 的格式存入文件，这样既能保证 Redis 重启时的速度，又能简单数据丢失的风险。

一、 RDB

1. 简述
在指定的时间间隔内将内存中的数据集快照写入磁盘，恢复时将快照文件直接读到内存中。达到恢复数据的实现。
Redis会单独创建（fork）一个进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换掉上次持久化好的文件；
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能；
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是很敏感，哪RDB方式比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能会丢失。

2. Fork
Frok的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量，环境变量，程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

3. RDB保存的文件是dump.rdb文件

4. 配置文件

save 900 1      #表示900秒内如果至少有 1 个 key 的值变化，则触发RDB
save 300 10     #表示300秒内如果至少有 10 个 key 的值变化，则触发RDB
save 60 10000   #表示60秒内如果至少有 10000 个 key 的值变化，则触发RDB

如果不需要 Redis 进行持久化，那么可以注释掉所有的 save 行来停用保存功能，也可以直接一个空字符串来停用持久化：save “”。

#在默认情况下，如果RDB快照持久化操作被激活（至少一个条件被激活）并且持久化操作失败，Redis则会停止接受更新操作。  
#这样会让用户了解到数据没有被正确的存储到磁盘上。否则没人会注意到这个问题，可能会造成灾难。  
#  
#如果后台存储（持久化）操作进程再次工作，Redis会自动允许更新操作。  
#  
#然而，如果你已经恰当的配置了对Redis服务器的监视和备份，你也许想关掉这项功能。  
#如此一来即使后台保存操作出错,redis也仍然可以继续像平常一样工作。  
stop-writes-on-bgsave-error yes  

#是否在导出.rdb数据库文件的时候采用LZF压缩字符串和对象？  
#默认情况下总是设置成‘yes’， 他看起来是一把双刃剑。  
#如果你想在存储的子进程中节省一些CPU就设置成'no'，  
#但是这样如果你的kye/value是可压缩的，你的到处数据接就会很大。  
rdbcompression yes  

对于存储到磁盘中的快照，可以设置是否进行压缩，如果配置yes，Redis会采用LZF算法进行压缩，如果不想消耗CPU来进行压缩，可以设置关闭此功能。

#从版本RDB版本5开始，一个CRC64的校验就被放在了文件末尾。  
#这会让格式更加耐攻击，但是当存储或者加载rbd文件的时候会有一个10%左右的性能下降，  
#所以，为了达到性能的最大化，你可以关掉这个配置项。  
#  
#没有校验的RDB文件会有一个0校验位，来告诉加载代码跳过校验检查。  
rdbchecksum yes  

在存储快照后，还可以让redis使用CRC64算法进行数据校验，这样做会增加大约10%的性能消耗，所以，为了达到性能的最大化，你可以关掉这个配置项。

# 导出数据库的文件名称  
dbfilename dump.rdb 

设置导出的快照文件名称。

5. RDB 手动触发

手动触发 Redis 进行 RDB 持久化的指令的为:

• save ，该指令会阻塞当前 Redis 服务器，执行 save 指令期间，Redis 不能处理其他命令，直到 RDB 过程完成为止。
• bgsave，执行该命令时，Redis 会在后台异步执行快照操作，此时 Redis 仍然可以相应客户端请求。具体操作是 Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。Redis 只会在 fork 期间发生阻塞，但是一般时间都很短。但是如果 Redis 数据量特别大， fork 时间就会变长，而且占用内存会加倍，这一点需要特别注意。
• 执行flushall命令，也会产生dump.rdb文件，但里面为空，没有意义。

二、 AOF

1. 简述
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录）只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据， redis重启的话会根据日志文件中的内容将写指令从前到后执行一次来完成数据的恢复工作。

2. AOF保存的文件是appendonly.aof文件

3. 配置文件

appendonly yes

开启AOF

appendfilename  appendonly.aof 

AOF保存文件名

 appendfsync 

AOF配置策略
有三个取值：

• always 同步持久化，每次发生数据改变会立即记录到磁盘，性能较差但数据完整性强
• everysec 出厂默认推荐，异步操作，每秒记录，执行写入AOF文件，如果一秒内宕机，有数据丢失
• no 不主动写入AOF，有操作系统去执行，最快但是不安全

4. AOF启动、修复、恢复
正常恢复：

• 修改默认的appendonly no 改为 yes
• 将有数据的AOF文件复制一份保存到对应目录
• 恢复 重启redis然后重新加载
  异常恢复：
• 备份被写坏的AOF文件
• 修复：Redis-check-aof --fix进行修复
• 恢复：重启redis然后重新加载

4. Rewrite
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增加了重写机制，当AOF文件的大小超过了所设定的阈值，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令 bgrewriteaof
重写原理：
AOF文件持续增长而过大时，会fork一条新进程来讲文件重写，遍历新进程的内存中的数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写一个新的aof文件。
触发机制：
redis会记录上次重写时的AOF文件大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

# 自动重写AOF文件。如果AOF日志文件增大到指定百分比，Redis能够通过 BGREWRITEAOF 自动重写AOF日志文件。
# 工作原理：Redis记住上次重写时AOF文件的大小（如果重启后还没有写操作，就直接用启动时的AOF大小）
# 这个基准大小和当前大小做比较。如果当前大小超过指定比例，就会触发重写操作
auto-aof-rewrite-percentage 100 #百分之百 即上次的一倍
auto-aof-rewrite-min-size 64mb

# 把这个设置成"yes"带来了延迟问题，就保持"no"，这是保存持久数据的最安全的方式
no-appendfsync-on-rewrite no #重写时是否可以运行 Appendfsync,

5. 优势

• 数据完整性强
  6. 劣势
• 相同数据集的数据而言，aof文件远大于rdb文件，恢复速度慢于rdb
• aof运行效率低于rdb，美妙同步策略效率较高，不同步效率和rdb相同

三、 总结

RDB持久化方式能够在指定的时间间隔内对数据进行快照存储
AOF持久化方式记录每次对服务器的写操作，当服务器重启的时候会重新执行这些命令恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾
redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大
只做缓存：如果只希望数据在服务器运行时存在，也可以不使用任何持久化方式
同时开启两种持久化方式：
在这种情况下，Redis重启时会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF?建议不这样，因为RDB更适合用于备份数据库（AOF在不断变化不好备份）。