Redis持久化

redis是一个内存数据库，当redis服务器重启，电脑重启后redis中的数据会丢失， 为了避免这种现象，可以将redis内存中的数据持久化保存到硬盘的文件中。

redis提供了两种持久化方式：

1. RDB：默认方式，不需要进行配置，在一定的间隔时间中，检测key的变化情况，然后持久化redis数据，并不保证所有的数据都会被持久化。

2. AOF：日志记录的方式，记录每一条命令的操作，可以每一次命令操作后 持久化数据。（类似于MySQL的更新方式，对性能有一定的影响）

   1. 编辑redis.windows.conf文件 appendonly no ---> appendonly yes

   2. 在命令行中重新启动redis服务器，并指定配置文件名称

RDB（Redis DataBase）

RDB其实就是把数据以快照的形式保存在磁盘上。什么是快照呢，你可以理解成把当前时刻的数据拍成一张照片保存下来。RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb，最好将这个文件做好备份。

RDB持久化方式——save与besave

save命令：同步，在主线程中保存快照；阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用；

bgsave命令：异步，Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。堵塞只发生在fork阶段，一般时间很短；BGSAVE命令是针对SAVE堵塞问题做的优化。因此Redis内部所有的设计RDB的操作都采用BGSAVE的方式，而save命令已经废弃。

bgsave流程：

 配置文件(snapshot部分)

#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
save 900 1
save 300 10
save 60 10000

# 当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。
# 提醒用户意识到RDB失效了，数据没有被持久化
stop-writes-on-bgsave-error yes

rdbcompression yes

rdbchecksum yes

# The filename where to dump the DB
dbfilename dump.rdb

# The working directory.
dir ./

1. 触发机制

   1. save的规则满足的情况下，自动执行BGSAVE

   2. 执行flushdb命令，会自动执行BGSAVE，但是生成的rdb文件是空的

   3. 执行shutdown退出redis，会自动执行BGSAVE

2. 恢复数据

   只需要将dump.rdb文件放在redis启动目录，reids启动的时候会自动恢复rdb文件中的数据

3. 优缺点

   1. 优点

      1. RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。

      2. 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

      3. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

   2. 缺点

      RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

      最后一次持久化之后的数据会丢失。

AOF（Append Only File）

redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。

1. 配置文件（APPEND ONLY MODE部分）

   #是否开启AOF备份，默认不开启，如果要使用AOF，一般只将这个改为yes即可
   appendonly no
   
   # The name of the append only file (default: "appendonly.aof")
   appendfilename "appendonly.aof"
   
   #三种持久化模式
   # appendfsync always
   appendfsync everysec
   # appendfsync no
   
   #重写规则
   no-appendfsync-on-rewrite no
   # 如果aof文件大于64mb，会fork一个新的进程重写aof文件
   auto-aof-rewrite-percentage 100
   auto-aof-rewrite-min-size 64mb

   如果aof备份文件被破坏，redis客户端将无法启动，可以使用redis-check-aof修复aof文件。

2. 优缺点

   1. 优点

      1. 该机制可以带来更高的数据安全性，最多丢失一秒数据。

      2. 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。

   2. 缺点

      1. 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

      2. 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。