最新基于内存的分布式NoSQL数据库Redis(六)AOF设计(1)

+ [知识点22：Redis持久化：AOF实现](#22RedisAOF_89)
+ [附录一：Jedis Maven依赖](#Jedis_Maven_147)

知识点21：Redis持久化：AOF设计

• 目标：掌握Redis的AOF持久化机制

• 路径

  • step1：问题
  • step2：AOF方案
  • step3：优缺点
  • step4：持久化方案

• 实施

  • 问题

  RDB存在一定概率的数据丢失，如何解决？
  
  

  • AOF方案

    • 思想

      • 按照一定的规则，将内存数据的操作日志追加写入一个文件中
      • 当Redis发生故障，重启，从文件中进行读取所有的操作日志，恢复内存中的数据
      • 重新对Redis进行执行，用于恢复内存中的数据

    • 过程

    

    • 实现：追加的规则

      • appendfsync always
        • 每更新一条数据就同步将这个更新操作追加到文件中
        • 优点：数据会相对安全，几乎不会出现数据丢失的情况
        • 缺点：频繁的进行数据的追加，增大磁盘的IO，导致性能较差
      • appendfsync everysec
        • 每秒将一秒内Redis内存中数据的操作异步追加写入文件
        • 优点：在安全性和性能之间做了权衡，性能要比always高
        • 缺点：有数据丢失风险 ，但最多丢失1秒
      • appendfsync no
        • 交给操作系统来做，不由Redis控制
        • 肯定不用的

  • 优缺点

    • 优点：安全性和性能做了折中方案，提供了灵活的机制，如果性能要求不高，安全性可以达到最高

    • 缺点

      • 这个文件是普通文本文件，相比于二进制文件来说，每次追加和加载比较慢

      • 数据的变化以追加的方式写入AOF文件

        • 问题：文件会不断变大，文件中会包含不必要的操作【过期的数据】
        • 解决：模拟类似于RDB做全量的方式，定期生成一次全量的AOF文件

  • 应用：数据持久化安全方案，理论上绝对性保证数据的安全

  • 持久化方案：两种方案怎么选？

    • 两种方案都可以用：默认不配置AOF，使用的RDB
    • 问题**：两种都用，**重启Redis加载的是谁的数据？
      • 加载AOF

• 小结

  • 什么是AOF机制？

    • 按照一定的规则将内存中的变化追加记录在一个日志文件中
    • 规则
    • always：内存变化一条，就追加磁盘一条，安全性高，性能差
      • everysesc：每一秒将这一秒内存的变化追加到磁盘中，安全和性能做了折中
      • no：不用
    • 优点
    • 安全和性能的选择更加灵活，安全性更高
    • 缺点
    • 追加到普通日志文件：相比于二进制来追加和恢复都要慢一些
      • 日志文件越来越大，里面会包含很多无用数据操作：根据规则来构建全量的AOF
    • 应用：Redis作为数据库或者缓存

知识点22：Redis持久化：AOF实现

• 目标：实现AOF持久化

• 实施

  • 开启并配置

  vim redis.conf
  #594行：开启aof
  appendonly yes
  #624行：默认每s刷写一次
  appendfsync everysec
  #665,666
  #增幅100%就重新覆盖一次
  auto-aof-rewrite-percentage 100
  #文件至少要大于64MB，一般建议更改为GB大小
  auto-aof-rewrite-min-size 64mb
  
  

  • 重启Redis

  shutdown
  redis-start.sh
  
  

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

需要这份系统化资料的朋友，可以戳这里获取