Redis教程

redis 持久化

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

redis 持久化

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

rdb

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

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

  • 优点:
    1. rdb 保存的是某一个时间点的全量数据,所以可以对每一个时间点的数据进行备份,在恢复的时候可以恢复到不同的版本
    2. rdb 持久化的时候 fork 一个子线程去执行,父线程继续执行自己的事情
    1. rdb 恢复数据的速度比 aof 快
  • 缺点:
    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 持久化的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!