RDB 持久化

• 方式：通过快照的方式进行持久化。

• 持久化时机：

  • 通过设置持久化规则进行持久化
  • 执行save和bgsave操作
  • 执行flushall操作
  • 执行主从复制操作

• 步骤：

  1. 父线程通过fork函数，复制一个子线程。
  2. 父线程接收新数据，子线程执行IO操作，将内存数据存储到新的rdb文件中。
  3. 当新的rdb持久化完成后，将旧的rdb文件覆盖。

• 缺点：如果redis突然宕机，会损失上一次快照到现在更新的数据。

• 控制参数：

  • save <seconds> <changes> 在seconds内至少有changes的键发生变化，触发快照

AOF持久化

• 方式：通过同步磁盘数据的方式进行持久化

• 持久化时机：开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件，这一过程显然会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘可以提高AOF的性能。

• 控制参数

  • appendonly yes 开启AOF持久化
  • 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 文件， 从而确保数据的一致性不会被破坏。
  解决方案：

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

如何选择RDB和AOF

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