本篇已收录至redis in action 学习笔记系列
关于 redis 的持久化基本上属于面试必问的部分
快照持久化
就是在系统的存储空间中生成一个 rdb 文件, 里面存储了快照命令开始触发之前, redis 服务器中的所有数据.
redis 执行快照的步骤
-
Redis调用fork函数创建一个子进程。
-
子进程将快照数据写入到临时RDB文件中。
-
当子进程完成数据写入操作后，再用临时文件替换老的文件。
什么时候执行一次快照?
-
达到 conf 中的快照相关的配置时
save 60 10000
- 当 60s 内发生了 10000 次写入时触发快照
-
redis server 收到了 shutdown 命令时, 会执行一次 save 命令, 阻塞所有写操作
-
当一个 redis 服务器连接另一个 redis 服务器, 并向对方发送一条 sync 命令时. 如果主服务器此时没有在 bgsave, 或者主服务器不是刚刚执行完 bgsave, 则会开始执行 bgsave.
快照机制适用的场景
-
即使丢一部分数据对应用程序影响不大的情况.
-
个人开发场景 (save 900 1)
-
对日志进行聚合计算, 或者对页面浏览量进行分析时
-
当 redis 服务器中数据占用内存达到 Xen 虚拟机 50 gb 时, 使用 bgsave 创建子进程都需要15秒, 生成快照则要20分钟. 如果是 save, 则需要3-5分钟.
优势和劣势
| 优势 | 劣势 |
|---|---|
| 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复. 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。 |
如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。 |
AOF持久化
redis 服务器上的每一次写操作, 都会将对应的命令写入到一个aof文件中. 所以当需要数据恢复时, 执行这个文件的所有写操作就可以恢复数据. 启用aof模式, 只需要对应的 conf 文件里将 appendfsync 的 value 改为 yes 即可.
文件同步原理:
使用任何语言执行磁盘中文件写入数据的操作时, 首先会将文件里面的内容加载至缓冲区, 然后写入的内容也会首先存储在缓冲区, 但是什么时间将缓冲区的内容存回磁盘中则需要系统进行判定. 所以用户可以使用同步命令将数据写入到磁盘的文件中, 以确保文件真正存储了我们要写入的内容.
aof 模式同步数据的频率级别
appendfsync
- always, 每次对 redis 服务器写入数据都执行一次 aof. 非常影响效率
- everysec, 每秒执行一次同步.
- no, 让操作系统决定什么时候应该执行一次同步.
一般使用的级别是 everysec.
如何解决 aof 文件过大问题
由于服务器长时间运行, 写入的数据越来越多, aof 文件相应的也会越来越大.
-
可以通过发送
bgrewriteaof命令, 重写aof文件, 将冗余的命令删除. 这个操作的原理与 bgsave 类似. 都是创建一个子进程, 通过子进程完成对文件的减负. -
可以通过执行
auto-aof-rewrite-percentage [100]和auto-aof-rewrite-min-size [65mb]选项来自动执行bgrewriteaof. 即当文件大小大于 65mb 时, 或者文件大小大于上一次重写文件后1倍时, 执行一次重写.
优势和劣势
| 优势 | 劣势 |
|---|---|
| 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。 AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。 |
对于相同数量的数据集而言，AOF文件通常要大于RDB文件。 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。 |