redis7.0.5数据持久化(RDB和AOF)

目前都是使用Redis作为数据缓存，缓存的目标主要是那些需要经常访问的数据，或计算复杂而耗时的数据。缓存的效果就是减少了数据库读的次数，减少了复杂数据的计算次数，从而提高了服务器的性能。

1.数据持久化原理

手动、定时、条件触发 持久化 都存在数据丢失问题

2.RDB持久化

2.1手动save命令

• 手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，
• 每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。
• 在默认配置中，Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中。
• 可以配置持久化策略：save N M，让redis在“N秒内至少有M个改动”才会触发一次rdb持久化操作。
• 例如redis的默认策略有：

save 900 1   -- 900秒内至少有一个改动
save 300 10		-- 300秒内至少有10个改动
save 60 10000	-- 60秒内至少有10000个改动

2.2手动bgsave命令

Redis借助了linux系统的写时复制（Copy-On-Write）技术，在生成快照的同时，仍然可以接收命令处理数据。简单来说，bgsave进程是由主进程fork生成的子进程，可以共享进程程所有的内存数据。bgsave进程中的线程运行后，开始读取主进程的内存数据，也就是redis的内存数据，将内存数据写入到dump.rdb文件中。此时，如果主进程处理的命令都是读操作，则bgsave线程不受影响。如果主进程处理了写操作，则会对该命令操作的数据复制一份，生成副本，bgsave进程中的线程会把这个副本写入到dump.rdb文件中，而在这个过程中，主进程仍可执行命令。

• 子进程 和父进程间的共享内存 只读
  

2.3save和bgsave对比

2.4RDB方式优缺点：

1. 缺点：
   RDB每次持久化需要将所有内存数据写入文件，然后替换原有文件，当内存数据量很大的时候，频繁的生成快照会很耗性能。
   如果将生成快照的策略设置的时间间隔很大，会导致redis宕机的时候丢失过多的数据。
2. 优点：
   因为dump.rdb文件是二进制文件，所以当redis服务崩溃恢复的时候，能很快的将文件数据恢复到内存之中。

2.5持久化优化（后面补充，主要是配置优化）

3.AOF持久化

为解决RDB方式丢失数据的问题，从1.1版本开始，redis增加了一种更加可靠的方式：AOF持久化方式。
在使用AOF方式时，redis每执行一次修改数据命令，都会将该命令追加到appendonly.aof文件中（先写入os cache，然后通过fsync刷盘）。
可以通过修改配置文件来使用AOF
aof数据格式

3.1AOF的开启

• 配置文件

appendonly yes

• 命令方式设置
  
• AOF可以配置三种刷盘策略：
  appendfsync always：每次执行写命令都会刷盘，非常慢，也非常安全。
  appendfsync everysec：每秒刷盘一次，兼顾性能和安全。
  appendfsync no：将刷盘操作交给系统，很快，不安全。
  推荐使用everysec，该策略下，最多会丢1秒的数据。
  
  调用 fsync 会发生阻塞

3.2 AOF重写:（重要）

因为appendonly.aof文件中存储的是执行命令，所以会产生很多没用的命令，因此，redis会定期根据最新的内存数据生成新的aof文件。

• 如下两个配置可以控制aop文件重写的频率：
  auto‐aof‐rewrite‐min‐size 64mb： – aof文件至少达到了64m才会触发重写
  auto‐aof‐rewrite‐percentage 100： – 距离上次重写增长了100%才会再次触发重写

• AOF也可以手动触发重写：bgrewriteof
  注意，AOF重写redis会fork出一个子进程去做(与bgsave命令类似)，不会对redis正常命令处理有太多影响

3.3 数据损坏和恢复

3.4 AOF持久化过程

3.5 RDB和AOF对比

config rewrite 会修改配置文件