Redis从入门到放弃（6）：持久化
1、引言
Redis作为一种高性能的内存数据存储系统，常被用作缓存、会话存储、消息队列等多种应用场景。然而，由于其数据存储在内存中，一旦发生意外或服务器重启，数据就会丢失。为了保障数据的持久性和安全性。
Redis提供了多种持久化方案：
- RDB（Redis DataBase）：按指定的时间间隔执行数据集的时间点快照。
- AOF（Append Only File）：记录服务器收到的每个写入操作。
- RDB + AOF：您还可以在同一实例中组合 AOF 和 RDB。
本文将探究以上三种持久化技术的工作原理、优缺点以及适用场景。
2、RDB持久化
RDB是Redis的默认持久化方式。它通过定期或手动执行快照将内存中的数据保存到磁盘上（dump.rdb）。触发RDB持久化过程分为手动触发和自动触发。
- 手动触发：可通过SAVE和BGSAVE命令完成。
- 自动触发：通过redis.conf文件增加save配置项完成，本质还是执行得BGSAVE命令。
那么SAVE和BGSAVE两个命令有什么区别呢？
SAVE：主线程操作，同步执行，会阻塞其它命令的执行。执行[save]命令时，RDB快照生成如果时间过长，后续请求会被阻塞，客户端新发送所有命令都会被拒绝。因此在生产环境中要谨慎使用该命令，避免影响服务的正常运行。
BGSAVE：写时复制，异步执行，不会阻塞其它命令的执行，会fork一个子进程进行操作，但这样比较消耗内存。主进程依旧保持与客户端的连接，正常执行读写命令。
2.1、手动触发
SAVE命令使用方法：
127.0.0.1:6379> SAVE
BGSAVE使用方法：
127.0.0.1:6379> BGSAVE
2.2、自动触发
RDB自动触发指的是通过在Redis的配置文件中设置特定的条件，使得Redis能够在满足这些条件时自动进行RDB持久化，而无需手动干预。这样可以确保数据定期地被保存到磁盘上，从而避免过多的数据丢失。
在Redis的配置文件redis.conf中，可以使用save配置项来设置RDB自动触发的条件。
save <seconds> <changes>
其中<seconds>表示多少秒内发生了<changes>次写操作，就会触发一次自动的RDB持久化。
可以设置多个save规则，每个规则独占一行，Redis会按照配置的顺序进行判断。例如：
save 900 1
save 300 10
save 60 10000
上述配置的意思分别是：在900秒内发生了至少1次写操作、在300秒内发生了至少10次写操作、在60秒内发生了至少10000次写操作时，Redis会自动触发RDB持久化。
3、AOF持久化
AOF持久化（Append Only File）以追加日志的形式记录Redis每个写操作并写入到一个文件中，即【appendonly.aof】文件。
AOF持久化过程可以简述如下：
-
写入操作记录：当Redis执行写操作时（如SET、INCR等），写入命令会追加到aof_buff（缓冲区）中。
-
文件同步：AOF缓冲区会根据配置定期进行同步到磁盘。
-
AOF重写：为了避免AOF文件过大，Redis会定期进行AOF重写，达到压缩文件得目的。
3.1、触发方式
在redis.conf配置文件中，开启配置（默认不开启）：
appendonly yes
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
持久化频率配置：
appendfsync always # 每个写命令都同步，新的命令追加到aof文件，慢但安全
appendfsync everysec # 每秒同步一次，丢失概率小
appendfsync no # 从不主动同步，交给操作系统决定何时同步
3.2、AOF重写
当满足触发条件时，Redis会扫描整个实例的数据，重新生成一个AOF文件来完成一些多余命令的过滤，从而削减了文件大小。
重写流程：主进程fork出一个子进程进行AOF文件的重写，子进程重写完毕后，主进程把子进程重写期间，其他客户端产生的写请求，追加到AOF文件中，替换旧文件。
重写是如何缩减文件大小的，如：
- 进程内已经超时的数据不再写入文件。
- 旧的AOF文件含有无效命令，如del key1、hdel key2等。重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
- 多条写命令可以合并为一个。
AOF有两种触发方式：
- 手动触发：直接调用bgrewriteaof命令。
- 自动触发：redis.config配置如下
auto-aof-rewrite-percentage 100 # 百分比，AOF文件的增长率达到
auto-aof-rewrite-min-size 64mb # AOF文件大小达到多少
上述配置的含义是，当AOF文件大小增长到当前AOF文件大小的100%时，Redis会自动触发AOF重写操作；同时，AOF文件大小至少达到64MB时，才会执行AOF重写。
4、混合持久化
在Redis4.0后新增了一种混合模式：RDB+AOF，将两者的优点进行整合，混合方式采用AOF方式记录数据的变化，采用RDB的方式进行二进制文件存储。也就是在写入的时候先把数据以RDB的形式写入文件的开头，再将后续的写命令以AOF格式追加到文件中。
redis.conf开启配置如下：
# 混合持久化开关
aof-use-rdb-preamble yes
5、RDB与AOF的优缺点对比
5.1、RDB
优点：
- 性能高：对Redis的性能影响较小，适用于要求高性能的场景。
- 适用于备份：生成的快照文件紧凑且压缩，适合用于备份和灾难恢复。
缺点：
- 数据丢失：定期生成快照，如果Redis发生故障，最后一次快照后的数据会丢失。
- 不适用于大规模数据：对于大规模数据集，可能导致长时间阻塞。
5.2、AOF
优点：
- 更高的数据安全性：记录每个写操作，数据更可靠，适用于要求数据实时持久性的场景。
- 数据可读性：AOF文件以易读的文本格式记录，方便查看和理解。
缺点：
- 相同数据集的数据而言AOF文件要远大于RDB文件，恢复速度慢于RDB
- AOF文件较大：随着写操作的增加，AOF文件会变得庞大。
综合来看，对于不同的应用场景，可以根据需求选择适合的持久化方式。RDB持久化适用于要求高性能和定期备份的场景；AOF持久化适用于要求数据实时持久性和较高数据安全性的场景；混合持久化则可以在兼顾数据实时性和备份需求的同时，提供更好的性能和数据保护。在配置持久化时，建议根据具体业务需求，综合考虑数据安全性、性能、存储空间等因素，选择合适的持久化策略。
