Redis 持久化

  • 持久化原因:
    客套话,redis基于内存的数据库,持久化数据到磁盘上,防止数丢失。

  • 持久化方式:
    aof 文件追加方式 
     
    默认文件名是appendonly.aof。保存路径同 RDB持久化方式一致,通过dir配置指定。AOF的工作流程操作:命令写入 (append)、文件同步(sync)、文件重写(rewrite)、重启加载 (load)
    1 所有的写入命令会追加到aof_buf(缓冲区)。
    2 aof缓冲区根据对应的策略向硬盘做同步操作。
    3 AOF文件逐渐增大,定期重写,达到压缩目的。{重写可手动触发或者自动触发}
    4 重启时,可加载AOF文件进行数据恢复
    优点:
       a 该机制可以带来更高的数据安全性,即数据持久性。Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中。
       b 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。
       c 如果日志过大,Redis可以自动启用rewrite机制。
       d AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。
    缺点:
       a 对于相同数量的数据集而言,AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
       b 根据同步策略的不同,AOF在运行效率上往往会慢于RDB。
  • rdb数据快照方式
    将redis 存在内存中的数据以快照的形式保存在本地磁盘中。存了一份dump.rdb文件。
    此方式分为手动备份和自动备份两大类。
    手动备份:
       
    save 命令,用主线程进行同步存储,会阻塞redis服务器。
     
    bgsave 命令,由于是异步的,它不会阻塞主进程继续收集请求,它会在通过fork()系统调用创建一个子进程将数据转储保存在一个名为temp-<bgsave-pid>. rdb的临时文件中。当转储过程结
              束后,这个临时文件会被重命名为由参数dbfilename定义的名字覆盖并保存在dire指定的本地目录中。
    自动备份:
       a.修改配置项 save m n即表示在 m 秒内执行了 n 次命令则进行备份.
       b.当Redis 从服务器项主服务器发送复制请求时,主服务器则会使用 bgsave命令生成 rbd 文件,然后传输给从服务器.
       c.当执行 debug reload 命令时也会使用 save 命令生成rdb文件.
       d.当使用 shutdown 命令关掉服务时,如果没有启用 aof方式实现持久化则会采用bgsave的方式做持久化.同时shutdown后面可以加备份参数[nosave|save].

    优点:
       1.文件实现的数据快照,全量备份,便于数据的传输.比如我们需要把A服务器上的备份文件传输到B服务器上面,直接将rdb文件拷贝即可.
       2.文件采用压缩的二进制文件,当重启服务时加载数据文件,比aof方式更快.
    缺点:
       1.rbd采用加密的二进制格式存储文件,由于Redis各个版本之间的兼容性问题也导致rdb由版本兼容问题导致无法再其他的Redis版本中使用.
       2.时效性差,容易造成数据的不完整性.因为rdb并不是实时备份,当某个时间段Redis服务出现异常,内存数据丢失,这段时间的数据是无法恢复的,因此易导致数据的丢失.

原文地址:https://www.cnblogs.com/junbaba/p/12911652.html