2024年最全基于内存的分布式NoSQL数据库Redis(六)AOF设计(2)，2024年最新大数据开发开发者-优快云博客

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

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

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

文章目录

- 知识点21：Redis持久化：AOF设计
  - 知识点22：Redis持久化：AOF实现
  - 附录一：Jedis Maven依赖

知识点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%就重新覆盖一次

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

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

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

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

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