Redis持久化

Redis持久化

简介

（1）关于持久化

• Redis是内存数据库，宕机后数据会消失。
• 为保证重启后快速恢复数据，要提供持久化机制。

（2）持久化方式

• ROB：将当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化)。

• AOF：将Redis执行的每次写命令记录到日志文件中，当Redis重启时再次执行命令来恢复数据。
  

RDB

1.简介

（1）主要功能

• 在指定的时间间隔内将内存中的数据集快照写入磁盘
• 恢复时再将硬盘快照文件直接读回到内存里。

（2）优缺点

• 占用空间小，便于传输，恢复速度较快。
• 但不保证数据完整性，并且数据的全量同步会影响服务器性能。

2.自动触发

（1）准备

• 为达到演示的效果，我们将触发条件进行修改，设定为五秒内有两次修改即可触发（时间次数同时满足）。

  

• 修改dump文件保存路径，改成自己想统一管理的路径（也是恢复数据时的读取路径）。

  

• 建议将快照文件配上端口号，再多redis场景下容易辨别来源。

  

（2）触发备份

• 我们在五秒内队数据库进行两次修改。

  

• 此时在dumpfiles文件夹下就会发现快照文件。

  

（3）文件恢复

• 将备份文件(dump.rdb)移动到 redis 安装目录并启动服务即可。
• 执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义。
• 服务与备份要做到分机隔离。

3.手动触发

（1）save

• redis提供了save和bgsave两个命令来生成rdb文件。
• 在主程序中执行会阻塞当前redis服务器，直到持久化工作完成。
• 生产环境中尽量不要使用。

（2）bgsave

• 执行后在后台异步进行快照操作，不会发生阻塞。

• 该触发方式会fork一个子进程由子进程复制持久化过程。

• 该触发方式会fork一个子进程由子进程复制持久化过程。

• 允许主进程同时可以修改数据。

  

4.其他

（1）快照时间

• 可以使用lastsave命令得到最后一次快照的时间戳。
• 通过date -d @xxx命令将时间戳转化为日期出现。

（2）rdb文件检查与修复

• redis-check -rdb 文件路径
• 此命令可以同时进行检查与修复。

（3）触发快照条件

• 配置文件中默认的快照配置。
• 手动执行save/bgsave命令备份。
• 执行flushall/flushdb命令也会产生dump.rdb文件（文件为空）。
• 执行shutdown且没有设置开启AOF持久化。
• 主从复制时，主节点自动触发。

（4）禁用快照

• 动态停止所有RDB保存规则的方法。

  redis-cli config set save
  

• 更改相应配置文件。

AOF

1.简介

（1）功能

• 通过保存Redis服务器所执行的写命令来记录数据库状态，以日志的形式来记录每个写操作。
• redis启动之初会读取该文件重新构建数据。
• 只许追加文件但不可以改写文件。
• 默认情况下未开启此功能。

（2）优缺点

• 性能高，可做紧急修复，更好的保存数据。
• 但与rdb文件相比数据较大，恢复速度较慢。

2.工作流程与写回策略

（1）工作流程

• 用户为命令来源，会有多个源头以及源源不断的请求命令。

• 在这些命令到达Redis Server 以后，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际是内存中的一片区域，命令达到一定量以后再写入磁盘，避免频繁的磁盘I0操作。

• AOF缓冲会根据AOF缓冲区同步文件的写回策略将命令写入磁盘上的AOF文件。

• 随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。

• 当Redis Server 服务器重启的时候会从AOF文件载入数据。

  

（2）写回策略

• Always

  • 每次事件循环都进行一次同步操作（写一个记一个）。

  • 在主进程的主线程中进行，会因阻塞特性导致挂起，此期间无法服务新的请求。

  • 但确实能够保证内存和硬盘中数据的一致性。

• Everysec

  • 每秒进行一次同步操作。
  • 通过后台I/O线程进行，因在子线程中进行，主线程并不会被阻塞，可以继续服务新的请求。
  • 内存和硬盘中的数据会有1秒的差别。

• No

  • 由操作系统控制同步操作。
  • 不阻塞主线程，但是数据一致性可能会偏差很大。

  

3.正常回复与异常回复

（0）配置文件

• 开启aof功能。

  

• 使用默认的每秒钟写回策略。

  

（1）正常恢复

• 在已经清空的数据库中加入三对键值对。

  

• 此时我们在指定的路径下可以看到生成的两个文件。

  

• 进入到appendonlydir中可以看到三条信息，证明多文件统一构成aof。

  数据记录由incr文件进行。

  

• 为证明是以aof形式的恢复，我们将快照文件删除并将appendonlydir备份。不要用mv备份，否则无效，仍会记录flushdb。

  

• 通过flushdb清空数据库，一定要随时清除rdb文件。

• 重启数据库发现数据库仍然为空，我们将目前appendonlydir文件夹替换为之前的备份。

• 再次重启数据恢复，说明flush操作也会被记录。

（2）异常恢复

• 人为在incr文件中加入乱码模拟文件出错。
• 重启数据库发现因文件异常重启失败。
• 通过异常修复命令: redis-check-aof --fix 进行修复，清除掉不符合规则的部分。
• 再次重启，成功。

4.AOF重写

（1）简介

• 为了解决 AOF 文件体积膨胀的问题，通过重写机制来对文件进行 “瘦身”。
• 重写过程由后台进程进行，在 fork 进程时是会阻塞住主线程的。
• 启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

（2）触发机制

• 自动触发：满足配置文件中的选项。

  

• 手动触发：客户端向服务器发送bgrewriteaof命令。

5.RDB-AOF混合持久化

（1）数据恢复顺序和加载流程

• 在同时开启rdb 和aof 持久化时，重启时只会加载 aof 文件，不会加载 rdb 文件。

• 当aof文件不存在时则会去加载rdb文件。

  

（2）同时开启的优势

• 当redis重启的时候会优先载入AOF文件来恢复原始的数据。
• RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。