前言

redis是内存数据库，如果不将内存中美好的数据库状态保存到磁盘中华，一旦你退出redis，n那么他的数据就会丢失，这也是它和MySql不一样的地方

其中的配置操作请参考前面那一篇文章

1、RDB

  • rdb操作就是在redis.conf的快照（SNAPSHOTTING）中设置
  • rdb默认保存的文件名是dump.rdb
  • save num1 num2: 在num1秒内修改了num2个key，那么他就出触发rdb的保存机制

运行过程：

  • 1、redis调用系统函数fork() ，创建一个子进程，现在就有了父进程和子进程。
  • 2、子进程将数据集写入到一个临时 RDB 文件中。父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。
  • 3、当子进程完成对临时RDB文件的写入时，redis 用新的临时RDB 文件替换原来的RDB 文件，并删除旧 RDB 文件。后子进程退出（fork一个进程入内在也被复制了，即内存会是原来的两倍）。

导入rdb文件：

  • 只要将rdb文件放在redis的启动目录就行，redis在启动时会自动检索并导入数据
  • 查看启动目录：config get dir

自动触发持久化的方式：

  • 1、根据redis.conf 配置里的SAVE m n 根据触发条件触发（用的是BGSAVE）
  • 2、主从复制时，主节点自动触发
  • 3、执行Shutdown 且没有开启AOF持久化
  • 4、flushall 命令用于清空 Redis 数据库，在生产环境下一定慎用，当 Redis 执行了 flushall 命令之后，则会触发自动持久化，把 RDB 文件清空

手动触发：

  • 1、save命令：该命令会阻塞当前Redis服务器，执行SAVE命令期间，Redis不能处理其他命令，直到RDB过程完成为止，同时会将新的替换旧的文件。显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷。
  • 2、bgsave命令：执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上Redis内部所有的RDB操作都是采用BGSAVE命令。

优点：

  • 适合大规模的数据操作
  • rdb文件是一个二进制文件，文件紧凑，全量备份，文件比较小。这种文件非常适合用于进行备份和灾难恢复
  • 对于数据的完整性要求不高（既是缺点也是优点）
  • 速度快

缺点:

  • 需要一定的时间间隔，如果redis意外宕机的话，可能会丢失最后一次的数据。如果你要保证数据完整性的话，这个方式就不可取，得考虑AOF
  • fork()出来的一个子进程，会占用一定的内存。如果在数据集大的话，而且内存紧张的话，可能fork的时间就会很长

2、AOF

以独立日志的方式将每次写的命令（及其参数）记录到 AOF 文件，重启时再重新执行AOF文件中的命令达到恢复数据的目的

配置：

  • 首先aof需要自己开启，redis是默认不开启的
  • 配置详情请看上一节学习介绍
  • aof文件名为appendonly.aof
  • aof同步有三个级别（详细请看配置文件）

如果aof文件不小心被改了，出现了错误怎么办？

  • 这个时候启动redis会失败
  • 可以通过redis-check-aof工具来检测和修复aof文件
  • 输入命令 redis-check-aof fixed appendonly.aof


redission 关闭atch dog_redis

  • 接下来就可以正常启动redis了

运行机制：主要分为四部分

  • 命令写入append
  • 文件同步sync
  • 文件重写rewrite
  • 重启加载load

优点：

  • 该机制可以带来更高的数据安全性，数据完整性，即数据持久性。
  • Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。
  • 每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。
  • 每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。
  • 还有一个就是不同步，嗯！肯定是速度最快！
  • 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
  • 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性
  • AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建

缺点：

  • AOF文件通常要大于RDB文件。同时恢复速度比较慢。
  • 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较低的，同步禁用策略的效率和RDB一样高效