Redis持久化方式

Redis中的持久化机制

说明:Redis提供了两种不同的持久化方法将数据持久到硬盘里面

• 快照(snapshoting)
  这种方式是在指定的时间间隔内将内存中的数据集快照写入磁盘，当然这也是redis默认的持久化方式，保存的文件以.rdb形式结尾的文件。因此这种方式也称为RDB方式。
• AOF(append only file) 只追加文件
  这种方式可以将客户端执行的写命令记录到日志文件中。

1.快照(Snapshot)

1.1特点

这种方式可以将某一时刻的所有数据都写入到硬盘中，也是redis默认开启的持久化方式，保存的文件是以.rdb形式结尾的文件。因此这种方式也称之为RDB方式。

1.2 快照生成方式

• 客户端方式：BGSAVE和SAVE指令
• 服务器配置自动触发

# 1.客户端生成方式之BGSAVE
a.客户端可以使用命令BGSAVE命令来创建一个快照，当接收到客户端的BGSAVE命令时，redis来调用fork
来创建一个子进程，然后子进程负责将快照写入到磁盘中，而父进程则继续处理命令请求

b.名词解释：在liunx系统中，fork()会产生一个和父进程完全相同的子进程。在刚开始的时候，父子进程
共享相同内存，直到父进程有了写写操作后，共享内存才会结束。

2.客户端方式之SAVE
a.客户端还可以使用SAVE命令来创建一个快照，接受到SAVE命令的redis服务器在快照创建之前将不再响应
其他任何命令。
b.注意：SAVE命令不常用，使用SAVE命令在快照创建之前，redis处于阻塞状态，无法对外服务。

3.服务器配置方式之满足配置自动触发
a.可以在redis.conf中配置了save选项，redis会在save选项满足条件之后自动触发一次BGSAVE命令，
如果设置了多个save配置选项，当其中任意一个配置条件满足，redis也会触发一次BGSAVE命令。

4.服务器接收到客户端shutdown命令
a.当redis通过shutdown指令接受到关闭服务器的请求时，会执行一个SAVE命令，阻塞所有的客户端，不再
执行客户端发送的任何命令，并且在SAVE命令执行完毕后关闭服务器。

1.3配置生成的快照名称和位置

a.修改生成快照名称
 dbfilename dump.rdb
b.修改生成位置
dir ./

2. 只追加日志文件

2.1特点

这种方式可以将所有客户端执行的写命令记录到日志文件中，AOF持久化会将被执行的写命令写到AOF文件末尾，以此来记录数据发生的变化。因此只要redis从头到尾执行一次AOF文件所包含的所有写命令，就可以恢复AOF文件的记录的数据集。

2.2开启AOF持久化

在redis的默认配置中AOF持久化机制是没有开启的，需要在配置文件中开启

  开启AOF持久化
- a.修改 appendonly yes 开启持久化
- b.修改appendfilename "appendonly.aof"指定生成文件名称
- 修改后，记得重启redis哦😒

2.3日志追加频率

• always【谨慎使用】
  说明：每个redis写命令都要同步写入硬盘，虽然可以备份所有的redis写数据，使得数据不会丢失，但是大量的写入操作，会导致redis处理命令的速度受到硬盘性能的限制。
• everysec【推荐】
  -说明：每秒执行一次同步显示的将多个写命令同步到磁盘。为了兼顾数据安全和写入性能，用户可以考虑使用everysec选项，让redis每秒执行一次的频率对AOF文件进行同步；redis每秒同步一次AOF文件时性能和不适应任何持久化特性时的性能相差无几。
• no【不推荐】
  说明：持久化的时机完全由操作系统决定，这个选项不会对redis性能带来影响但是当系统崩溃时，会丢失不定量的数据。

2.4修改日志同步频率

2.5AOF文件的重写

2.5.1AOF带来的问题

aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条 set test 100就够了。为了压缩aof的持久化文件Redis提供了AOF重写机制

2.5.2AOF重写

用来在一定程度上减小AOF体积

2.5.3AOF触发重写方式

- 1.执行BGREWRITEAOF命令  不会阻塞redis的服务
- 2.配置redis.conf中的auto-aof-rewrite-percentage选项 参见下图
- 如果设置auto-aof-rewrite-percentage的值为100和auto-aof-rewrite-min-size 64mb,并且启用AOF持久化，那么当aof文件体积大于64mb,并且aof文件的体积比上一次大了至少一倍(100%),会自动触发，如果重写过于频发，可以考虑将auto-aof-rewrite-percentage设置更大。

2.5.4重写原理

注意：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据内容用命令的方式重写了一个新的aof文件，替换原来的文件。

重写流程
-1.redis调用fork ，现在有父子两个进程 子进程根据内存中的数据库快照，往临时文件中写入重建数据库
   状态的命令
-2.父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。
   这样就能保证如果子进程重写失败的话并不会出问题。
-3.当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写
   命令也写入到临时文件。
-4.现在父进程可以使用临时文件替换老的aof文件，并重命名后面收到的写命令也开始往新的aof文件中追加。

3.持久化总结

两种持久化方案既可以同时使用(aof),又可以单独使用,在某种情况下也可以都不使用,具体使用那种持久化方案取决于用户的数据和应用决定
无论使用AOF还是快照机制持久化,将数据持久化到硬盘都是有必要的,除了持久化外,用户还应该对持久化的文件进行备份(最好备份在多个不同地方)