redis持久化

Redis 持久化

Redis 是一个内存数据库， 为了保证数据的持久性， 它提供了三种持久化方案:

• RDB 方式（默认）
• AOF 方式
• 混合持久化（Redis 4.0以上）

RDB

介绍

• RDB 是 Redis 默认采用的持久化方式。

• RDB 方式是通过快照（snapshotting）完成的，当符合一定条件时 Redis 会自动将内
  存中的数据进行快照并持久化到硬盘。

• Redis 会在指定的情况下触发快照 。

  • 符合自定义配置的快照规则。
  • 执行 save 或者 bgsave 命令。
  • 执行flushall命令。
  • 执行主从复制操作。

• RDB配置信息（在redis.conf中设置自定义的快照规则）

  • RDB 持久化条件 save <seconds> <changes>

    示例：
    save 900 1 		# 表示 15 分钟（900 秒钟）内至少 1 个键被更改则进行快照。
    save 300 10 	# 表示 5 分钟（300 秒）内至少 10 个键被更改则进行快照。
    save 60 10000 	# 表示 1 分钟内至少 10000 个键被更改则进行快照。
    # 可以配置多个条件（每行配置一个条件），每个条件之间是“或” 的关系。
  

  • 配置 dir 指定 rdb 快照文件的位置 。
    dir ./
  • 配置dbfilename指定rdb快照文件的名称。
    dbfilename dump.rdb

  Redis 启动后会读取 RDB 快照文件，将数据从硬盘载入到内存

  根据数据量大小与结构和服务器性能不同，这个时间也不同。通常将记录一千万个字符串类型键、大小为 1GB 的快照文件载入到内存中需要花费 20～ 30 秒钟

快照实现原理

• 快照过程

  1. redis 使用 fork 函数复制一份当前进程的副本(子进程)

  2. 父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件。

  3. 当子进程写入完所有数据后会用该临时文件替换旧的 RDB文件，至此，一次快照操作完成。

• 注意事项

  • redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。
  • 这就使得我们可以通过定时备份 RDB 文件来实现 redis 数据库的备份， RDB 文件是经过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。

RDB优缺点

• 优点： RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无序执行任何磁盘 I/O 操作。同时这个也是一个缺点，如果数据集比较大的时候， fork 可以能比较耗时，造成服务器在一段时间内停止处理客户端的请求。
• **缺点 **： 使用 RDB 方式实现持久化，一旦 Redis 异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，希望将损失降到最小，则可以使用 AOF 方式进行持久化。

AOF

介绍

• 默认情况下 Redis 没有开启 AOF（append only file）方式的持久化
• 开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令， Redis 就会将该命令写入硬盘中的 AOF 文件，这一过程显然会降低 Redis 的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高 AOF 的性能。
• 可以通过修改 redis.conf 配置文件中的 appendonly 参数开启
  appendonly yes
• AOF文件的保存位置和 RDB 文件的位置相同，都是通过 dir 参数设置的。
  dir ./
• 默认的文件名是 appendonly.aof，可以通过 appendfilename 参数修改。
  appendfilename appendonly.aof

AOF重写原理（优化AOF文件）

• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写

• 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。

• 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕， Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。

• 参数说明

  auto-aof-rewrite-percentage 100 
  #表示当前 aof 文件大小超过上一次 aof 文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时 aof 文件大小为准
  auto-aof-rewrite-min-size 64mb 
  #限制允许重写最小 aof 文件大小，也就是文件大小小于 64mb 的时候，不需要进行优化
  

同步磁盘数据

Redis 每次更改数据的时候， aof 机制都会将命令记录到 aof 文件，但是实际上由于操作系统的缓存机制， 数据并没有实时写入到硬盘，而是进入硬盘缓存。 再通过硬盘缓存机制去刷新到保存到文件

• 参数说明

  appendfsync always 
  # 每次执行写入都会进行同步,这个是最安全但是是效率比较低的方式
  appendfsync everysec 
  # 每一秒执行
  appendfsync no 
  # 不主动进行同步操作，由操作系统去执行，这个是最快但是最不安全的方式
  

AOF文件损坏后恢复

服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。

• 修复方法。
  1. 为现有的 AOF 文件创建一个备份。
  2. 使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。
     redis-check-aof --fix readonly.aof
  3. 重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复 。

如何选择RDB和AOF

• 一般来说,如果对数据的安全性要求非常高的话， 应该同时使用两种持久化功能。
• 如果可以承受数分钟以内的数据丢失，那么可以只使用 RDB 持久化。
• 有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF恢复的速度要快 。
• 两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话， 那么 Redis重启时，会优先使用 AOF 文件来还原数据 。

混合持久化

介绍

• 重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。

• AOF在重写(aof文件里可能有太多没用指令，所以aof会定期根据内存的最新数据生成aof文件)**时将重写这一刻之前的内存rdb快照文件的内容和增量的 AOF修改内存数据的命令日志文件存在一起，都写入新的aof文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换；

• AOF根据配置规则在后台自动重写，也可以人为执行命令bgrewriteaof重写AOF。 于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

• 开启混合持久化,可以通过修改 redis.conf 配置文件中的 aof-use-rdb-preamble 参数开启：

  aof-use-rdb-preamble yes