Redis持久化后，如何彻底放弃？

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文件只保留最终数据的写入命令。 多条写命令可以合并为一个。