一、AOF
1、AOF 是什么
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
2、AOF默认不开启，需要手动在配置文件中配置
# AOF 持久化开启 # appendonly no # AOF 文件的名称 # appendfilename "appendonly.aof" # AOF 持久化策略 # appendfsync always # appendfsync everysec # appendfsync no
3、可以在redis.conf中配置文件名称，默认为 appendonly.aof
# AOF 文件的名称 # appendfilename "appendonly.aof"
4、AOF文件的保存路径，同RDB的路径一致
5、AOF和RDB同时开启，redis听谁的？
以 AOF 为准，因为 AOF 里面保存的数据比较完整。
6、AOF文件故障备份
AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载；
AOF和RDB同时开启，系统默认取AOF的数据；
7、AOF文件故障恢复
AOF文件的保存路径，同RDB的路径一致。
如遇到AOF文件损坏，可通过下面的命令进行恢复：
redis-check-aof --fix appendonly.aof 进行恢复
遇到的报错一般如下：
# oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo # Redis version=5.0.10, bits=64, commit=00000000, modified=0, pid=121, just started # Configuration loaded * Running mode=sentinel, port=26379. # Sentinel ID is b9715439b50e476eac19d423906edfad904006fb # +monitor master redismaster 100.127.64.21 6379 quorum 2 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo # Redis version=5.0.10, bits=64, commit=00000000, modified=0, pid=120, just started # Configuration loaded * +slave slave 100.127.64.19:6379 100.127.64.19 6379 @ redismaster 100.127.64.21 6379 * Running mode=standalone, port=6379. # Server initialized * Reading RDB preamble from AOF file... * Reading the remaining AOF tail... # Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename> * +sentinel sentinel 09533b1fd689c178ace11264b1474948dff10189 100.127.64.21 26379 @ redismaster 100.127.64.21 6379 * +sentinel sentinel 7a6a997019bdf8a95c57b494701f4877a5cb5edc 100.127.64.19 26379 @ redismaster 100.127.64.21 6379
8、AOF同步频率设置
AOF 提供了三种保存策略：
# AOF 持久化策略 # appendfsync always # appendfsync everysec # appendfsync no
说明：
appendfsync always：始终同步，每次Redis的写入都会立刻记入日志 appendfsync everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。 appendfsync no：把不主动进行同步，把同步时机交给操作系统
9、Rewrite
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
10、Redis如何实现重写？
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
11、何时重写
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
-
auto-aof-rewrite-percentage：这个配置项指定了AOF文件增长率的百分比阈值。当AOF文件的大小超过上一次重写时的大小的这个百分比时，Redis会触发AOF重写。默认值通常为100%，意味着AOF文件大小翻倍时会触发重写。
-
auto-aof-rewrite-min-size：这个配置项指定了AOF文件的最小大小阈值。只有当AOF文件的大小超过这个值时，才会考虑上述的百分比增长条件来触发重写。默认值通常为64MB。
12.AOF的优缺点
AOF的优点
- 数据完整性高：AOF通过保存每次写操作的命令来确保数据的完整性，即使发生宕机，也可以通过重新执行AOF文件中的命令来恢复数据，从而最小化数据丢失。
- 实时性：AOF可以配置为每秒同步一次或每次写操作都同步，从而提供较高的实时性。
- 易于理解和修改：AOF文件是以纯文本形式存储的，易于理解和修改（尽管不推荐直接修改AOF文件）。
- 支持多种同步方式：Redis提供了多种AOF同步策略，可以根据性能和数据安全性的需求进行选择。
AOF的缺点
- 文件体积大：随着时间的推移，AOF文件可能会变得非常大，占用大量的磁盘空间，并影响Redis的启动和恢复速度。
- 恢复速度慢：在Redis启动时，需要重新执行AOF文件中的命令来恢复数据，如果AOF文件很大，恢复过程可能会非常耗时。
- 对写性能的影响：当使用较高的同步策略时（如
always），每个写操作都需要等待磁盘I/O操作完成，可能会降低Redis的写性能。 - 重写过程可能占用资源：AOF重写是一个资源密集型的操作，需要创建子进程来执行，可能会占用大量的CPU和内存资源。
13.RDB的优缺点
RDB的优点
- 文件体积小：RDB文件是Redis数据库在某个时间点的内存快照，通常比AOF文件小得多，便于存储和传输。
- 恢复速度快：由于RDB文件只保存了内存快照，恢复数据时只需要加载一次文件，可以快速地恢复数据。
- 对系统性能影响小：RDB持久化过程由子进程负责，减少了主线程的负载，对系统性能影响较小。
- 适用于备份和容灾：RDB文件是一个紧凑的二进制文件，非常适合用于备份和容灾恢复。
RDB的缺点
- 数据实时性低：RDB是间隔一段时间进行持久化，无法做到实时持久化，如果在这一间隔内发生故障，可能会丢失数据。
- 可能存在兼容性问题：Redis演进过程中存在多个格式的RDB版本，可能存在老版本Redis无法兼容新版本RDB文件的问题。
- 恢复时可能丢失数据：如果Redis在生成RDB文件之前崩溃，将会丢失最后一次持久化后的数据。
- 可读性低：RDB文件是一个二进制文件，不是易于读取和理解的文本文件，不便于进行数据恢复、备份和分析。