备份AOF持久化与恢复

启用AOF：

appendonly no 改为yes

appendfsync everysec

将它改为：

• always：表示每个Redis命令都要立即写入到AOF文件，但这可能会影响性能。
• everysec：表示每秒钟同步一次AOF文件。
• no：表示完全依赖操作系统的缓冲区，这是最快的选项，但也是最不安全的。

1. always:

• • 描述: 每次写入 AOF 文件时都会立即同步到磁盘。
  • 优点: 提供最高的数据安全性，几乎不会丢失数据。
  • 缺点: 由于每次写入都需要同步磁盘，这可能会显著降低 Redis 的写入性能。
  • 适用场景: 如果数据安全性至关重要，即使性能有所牺牲也在所不惜。

1. everysec:

• • 描述: 每秒同步一次 AOF 文件到磁盘。
  • 优点: 提供较好的性能和较高的数据安全性。即使 Redis 服务在某一时刻崩溃，最多只会丢失一秒内的数据。
  • 缺点: 在极端情况下可能会丢失一秒内的数据。
  • 适用场景: 对大多数应用程序来说，这是一个很好的折衷方案，既能保证数据安全又不会显著影响性能。

1. no:

• • 描述: 不主动同步 AOF 文件到磁盘，而是依赖操作系统的缓冲机制。
  • 优点: 提供最佳的写入性能。
  • 缺点: 数据安全性较低，可能会丢失更多的数据。
  • 适用场景: 如果数据安全性不是首要考虑因素，并且需要尽可能高的性能。

推荐设置

对于大多数应用程序，推荐使用 everysec 作为 appendfsync 的设置。这样可以在数据安全性和性能之间达到一个良好的平衡。即使 Redis 服务突然崩溃，最多也只能丢失一秒内的数据。

关键参数解释如下：

appendonly yes：启用 AOF 持久化。

appendfilename "appendonly.aof"：设置 AOF 文件的名称。

appendfsync everysec：每秒钟将 AOF 缓冲区的内容同步到磁盘。这是一个较为平衡的选择，既保证了一定程度的数据安全性，又不会对性能造成太大影响。

no-appendfsync-on-rewrite no：在 AOF 重写期间仍然执行 appendfsync，以避免在此期间丢失数据。

auto-aof-rewrite-percentage 100 和 auto-aof-rewrite-min-size 64mb：当 AOF 文件大小达到原始大小的 100% 且超过 64MB 时，Redis 会自动触发 AOF 重写。

省流版：

1. 更改redis.conf文件参数appendonly no 改为yes，appendfsync everysec启动AOF
2. redis宕机
3. 将想要替换的appendonly.aof(来源于手动cp备份)替换到aof文件生成位置，重启redis，恢复数据。

注意：AOF 文件和 RDB 文件都将保存在同一目录下