标签：aof 持久 AOF bgsave rdb redis RDB 快照 save

由于redis的数据都直接存储在内存里，在服务器发生宕机时内存的数据会瞬间清空，那么必须要有重启时恢复数据的方法。
redis通过持久化机制将数据存储到磁盘中从而在服务器重启时恢复数据，这篇文章主要简介redis的持久化机制。

• rdb：rdb是通过快照的方式实现持久化，redis定期将数据集快照写入磁盘。

  • 触发RDB持久化过程分为手动触发和自动触发。手动触发的命令为save和bgsave。
    save：会阻塞主进程，一般不使用；bgsave：fork操作创建子进程，子进程执行，完成后自动结束，阻塞只发生在fork阶段，阻塞时间很短。
    自动触发都是通过bgsave的方式执行（save配置、从节点发送同步请求后主节点通过bgsave然后发送给从节点、默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave）
  • save配置：
    save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
    save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
    save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
  • rdb的优点：
    • RDB是一个紧凑压缩的二进制文件，代表Redis在某一个时间点上的数据快照。非常适合用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。
    • Redis加载RDB恢复数据远远快于AOF方式。
  • rdb的缺点：
    • RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
    • RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。

• aof：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

  • 由于aof文件可能会变得很大，提供了文件重写机制，分为自动重写和手动重写
  • aof配置：
    appendfsync always # 每次有数据修改发生时都会写入AOF文件。
    appendfsync everysec # 每秒钟同步一次，该策略为AOF的缺省策略。
    appendfsync no # 从不同步。高效但是数据不会被持久化。

• 此外，redis4.0还推出了混合持久化策略，解决了重启时使用aof恢复慢和rdb保存时效不高的问题，有兴趣的读者可以自行了解。

标签：aof,持久,AOF,bgsave,rdb,redis,RDB,快照,save
来源： https://www.cnblogs.com/fcb-it/p/12920217.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。