redis 持久化

本文主要是介绍redis 持久化，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

redis 持久化

便于灾难恢复，相当于高可用，在 redis 宕机之后可以很快的恢复数据，保证数据不丢失。默认俩种持久化都开启时，redis 使用 aof 恢复数据

rdb

快照方式，每次存储记录的时候都是通过 fork 出一个子线程，子线程首先将数据存放到一个临时文件中，等到将数据写完后，在采用原子的方式将旧的 dump.rdb 文件替换掉

fork：Linux fork 函数，对本来的进程复制出一份子进程，父进程可以继续做自己的事情（响应客户端的写操作），子进程进行 rdb 的写磁盘

• 优点：

1. 1. rdb 保存的是某一个时间点的全量数据，所以可以对每一个时间点的数据进行备份，在恢复的时候可以恢复到不同的版本
   2. rdb 持久化的时候 fork 一个子线程去执行，父线程继续执行自己的事情
2. 1. rdb 恢复数据的速度比 aof 快

• 缺点：

1. 1. 容易丢失数据，因为 rdb 持久化的时候是根据每秒有多少数据写来完成，如果这个时候机器坏了，就会丢失这些数据
   2. 如果数据量大的话，fork 的子线程就会频繁的 io ，影响性能

使用方式：save <seconds> <changes>

save "" 禁用 rdb

例如：save 60 1 ：六十秒内有一个 set 操作就会备份，如果这六十秒内 redis 宕机，就会丢失这部分数据

aof

日志记录，以追加文件的方式来持久化，每当有新的写命令，就将命令追加到日志文件中

fsync：强制刷新 os 缓存到磁盘

• 优点

  • 比 rdb 方式更加持久，因为 redis 提供了三种 fsync(强制刷新) 策略来写入磁盘，fsync 也相当于 fork 出一个子线程，然后来处理日志记录，父线程继续处理业务请求

    • always：每一条指令都写入磁盘，频繁的 io，不推荐

    • everysec：每秒写入一次，默认

    • no：交给操作系统来完成，没有保障

  • redis 可以在后台对日志文件进行重写，减少冗余，在重写的时候会新创建一个 aof 文件，而如果有写入命令还是会追加到原来的文件并且在内存中缓存一份，当新文件重写完后，会通知父线程，然后用新的文件替换旧的文件，并将缓存中的记录加入新的文件中，在 redis 4 之后对重写做了优化，在重写的时候不需要重写原来的命令，而是会生成一个 rdb 快照，加入 aof 文件中，然后替换原来的 aof 文件，以后直接追加在这个 aof 文件后即可

是否开启使用 rdb 快照方式

aof-use-rdb-preamble yes

可以手动执行命令重写或者达到条件自动重写

命令：BGREWRITEAOF

auto-aof-rewrite-percentage 100：百分比

auto-aof-rewrite-min-size 64mb：aof 文件大小

• aof 的文件比较容易看懂，如果不小心执行了 flushall 命令，在你没有重写 aof 的前提下，可以找到 aof 文件，删除最后的 flushall 命令，然后做数据恢复

• 缺点

  • aof 的体积要比 rdb 大，恢复的时候也比较慢，因为需要重新执行命令

模拟恢复数据

当同时开始 rdb 和 aof 的时候，恢复时会使用 aof 文件，因为 aof 文件保存的更完整

1、rdb

使用 save 命令，保存当前时刻的全量数据，将 dump 文件替换掉原来的 dump 文件，重启 redis，就会重新使用新的 rdb 文件恢复数据

这篇关于redis 持久化的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！