redis持久化

前言：redis持久化的意义

Redis作为分布式缓存架构中重要的一环，用于保存一些较为重要的数据，抗住系统的高并发访问。因此Redis中的数据必须持久化，防止服务或系统宕机导致数据丢失。

redis支持两种持久化方式 AOF 与 RDB

AOF的是操作记录 : AOF则是以追加的方式记录Redis执行的每一条写命令。

RDB 存储的是二进制文件

RDB 和 AOF 是可以同时开启的，在这种情况下，当Redis重启的时候会优先载入 AOF 文件来恢复原始的数据。

RDB

RDB 是 Redis 默认的持久化方式（AOF默认是关闭的），它将 Redis 在内存中的数据写入到硬盘中，生成一个快照文件。

dump.rdb

优点

RDB的优点是快速、简单，适用于大规模数据备份和恢复。由于 RDB 文件是以二进制格式保存的，因此它非常紧凑，并且在 Redis 重启时可以迅速地加载数据。相比于AOF，RDB文件一般会更小。

缺点

RDB也有缺点，例如数据可能会丢失，因为 Redis 只会在指定的时间点生成快照文件。如果在快照文件生成之后，但在下一次快照文件生成之前服务器宕机，那么这期间的数据就会丢失。

触发方式

RDB 持久化触发有两种方式：自动 和 手动。

自动

设置自动的方式（redis.config）

红方块里的就是具体的触发配置它的对应翻译解释是上方英文

大概意思个人连理解带翻译  第一个  sava 900 1  就是当  900秒内 有一个 key发生变化 就save（保存）

自动方式是指通过服务器配置文件的 save 选项，来让 Redis 每隔一段时间自动执行 bgsave ，本质上还是通过 bgsave 命令去实现。

配置文件的 save 选项允许配置多个条件，只要其中任何一个条件满足，就会触发 bgsave。

手动

• save：save 命令会阻塞 Redis 服务器进程，直到 RDB 文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。

• bgsave：bgsave 命令会 fork 一个子进程（注意是子进程，不是子线程）在后台生成快照文件，不会阻塞 Redis 服务器，服务器进程（父进程）可以继续处理命令请求。（bgsave命令执行期间，客户端发送的 save 和 bgsave 命令会被拒绝，这样的目的是为了防止父进程和子进程之间产生竞争。）

AOF

以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以 打开文件看到详细的操作记录Aof是增量持久化方式，每一条修改操作的命令都会持久化到 AOF 文件，在发生故障后可以做到不丢数据或丢失较少的数据

优点

aof持久化的最大优点是数据的安全性。 通过合理的同步策略，可以保证不会丢失太多的数据。 即使AOF文件出现了写入错误或者损坏，也可以通过`redis-check-aof`工具来修复AOF文件，或者通过`redis-check-rdb`工具来从AOF文件中恢复RDB文件。

缺点

AOF文件的大小通常比RDB文件大，因为AOF文件记录了所有的写命令，而RDB文件只记录了数据的快照。AOF文件过大会影响重写的效率和恢复的速度，也会占用更多的磁盘空间。
AOF持久化的性能通常比RDB持久化低，因为AOF持久化需要对每个写命令进行同步操作，而RDB持久化只需要定期执行快照操作。特别是在`always`同步策略下，AOF持久化会显著降低Redis的吞吐量。

触发方式（如何开启Aof模式）

根据配置文件中的`appendfsync`选项，有三种同步策略：
       `always`：每个写命令都同步写入到AOF文件，这样可以保证不会丢失任何数据，但是性能会很差。
       `everysec`：每秒钟同步一次写入到AOF文件，这样可以保证最多丢失一秒钟的数据，同时性能也比较高，这是默认的策略。
       `no`：完全由操作系统决定何时同步写入到AOF文件，这样可以提供最高的性能，但是也可能会丢失不定时长的数据。