redis持久化机制
一、Redis的持久化
Redis是一个基于内存的数据库，它的数据是存放在内存中，内存有个问题就是关闭服务或者断电会丢失。Redis的数据也支持写到硬盘中，这个过程就叫做持久化。
Redis提供了2种不同形式的持久化方式：
1、RDB持久化：将Redis在内存中的数据以快照的形式写入磁盘，恢复时通过读取RDB文件将数据加载到内存中。RDB持久化提供了很好的性能和压缩比，适用于需要定期备份数据的场景；
2、AOF持久化：将Redis在内存中的每个写命令以追加的方式写入磁盘，恢复时通过重放AOF文件中的命令来还原数据。AOF持久化提供了更加可靠的数据保护，但也会造成一定的性能损失。
二、Redis的默认持久化方式
Redis的默认持久化方式是RDB持久化。当开启RDB持久化功能时，Redis会周期性地将内存中的数据以快照的形式写入磁盘。默认情况下，Redis会在900秒内发生了至少1个键值对的变化时，才会开始进行RDB持久化操作。
可以通过redis.conf配置文件中的以下两个参数来控制RDB持久化的行为：
-
save：定义了多少秒内发生了多少次写操作后，Redis就会执行一次RDB持久化操作。比如save 900 1表示900秒内有至少1个键值对被修改时，Redis就会执行一次RDB持久化操作。
-
stop-writes-on-bgsave-error：如果这个选项被设置为yes，在RDB持久化失败的时候，Redis将停止接收写入操作，直到手动修复磁盘上的RDB文件为止。如果这个选项被设置为no，在RDB持久化失败的时候，Redis将继续接收写入操作，并尝试在下一次RDB持久化操作时修复RDB文件。
需要注意的是，RDB持久化只是一种备份机制，不适用于要求实时数据同步或者数据更新频繁的场景。在这种情况下，建议使用AOF持久化方式。
三、Redis的持久化方式选择
-
如果数据不能丢失，RDB和AOF混用
-
如果只作为缓存使用，可以承受几分钟的数据丢失的话，可以只使用RDB。
-
如果只使用AOF，优先使用everysec的写回策略。
当Redis同时开启了RDB和AOF持久化时，如果在恢复数据时两种持久化方式都存在，Redis会优先选择AOF持久化来进行数据恢复。这是因为AOF持久化记录了每个写操作的日志，相比之下提供了更加可靠的数据完整性和一致性。
在实际情况下，即使开启了两种持久化方式，通常也建议以AOF持久化作为主要的持久化方式，并且可以在必要时创建RDB快照作为备份。这样做的好处是能够确保数据的持久化和一致性，并且在发生故障时能够更快地进行数据恢复。
总之，尽管Redis支持同时使用RDB和AOF持久化，但是在实际应用中还是需要根据业务需求和数据安全性的考量来选择合适的持久化方式。
四、AOF持久化机制
AOF是执行完命令后才记录日志的。为什么不先记录日志再执行命令呢？这是因为Redis在向AOF记录日志时，不会先对这些命令进行语法检查，如果先记录日志再执行命令，日志中可能记录了错误的命令，Redis使用日志回复数据时，可能会出错。
正是因为执行完命令后才记录日志，所以不会阻塞当前的写操作。但是会存在两个风险：
-
当执行完命令还没记录日志时，宕机了会导致数据丢失
-
AOF不会阻塞当前命令，但是可能会阻塞下一个操作。
这两个风险最好的解决方案是折中妙用AOF机制的三种写回策略 appendfsync：
-
always，同步写回，每个子命令执行完，都立即将日志写回磁盘。
-
everysec，每个命令执行完，只是先把日志写到AOF内存缓冲区，每隔一秒同步到磁盘。
-
no：只是先把日志写到AOF内存缓冲区，有操作系统去决定何时写入磁盘。
always同步写回，可以基本保证数据不丢失，no策略则性能高但是数据可能会丢失，一般可以考虑折中选择everysec。
如果接受的命令越来越多，AOF文件也会越来越大，文件过大还是会带来性能问题。日志文件过大怎么办呢？AOF重写机制！就是随着时间推移，AOF文件会有一些冗余的命令如：无效命令、过期数据的命令等等，AOF重写机制就是把它们合并为一个命令（类似批处理命令），从而达到精简压缩空间的目的。
AOF重写会阻塞嘛？AOF日志是由主线程会写的，而重写则不一样，重写过程不会阻塞客户端的读写操作，因为重写过程是由后台子进程bgrewriteaof完成。
-
AOF的优点：数据的一致性和完整性更高，秒级数据丢失。
-
缺点：相同的数据集，AOF文件体积大于RDB文件。数据恢复也比较慢。
五、RDB持久化机制
因为AOF持久化方式，如果操作日志非常多的话，Redis恢复就很慢。有没有在宕机快速恢复的方法呢，有的，RDB！
RDB，就是把内存数据以快照的形式保存到磁盘上。和AOF相比，它记录的是某一时刻的数据，，并不是操作。
什么是快照?可以这样理解，给当前时刻的数据，拍一张照片，然后保存下来。
RDB持久化，是指在指定的时间间隔内，执行指定次数的写操作，将内存中的数据集快照写入磁盘中，它是Redis默认的持久化方式。执行完操作后，在指定目录下会生成一个dump.rdb文件，Redis 重启的时候，通过加载dump.rdb文件来恢复数据。RDB触发机制主要有以下几种：
RDB通过bgsave命令的执行全量快照，可以避免阻塞主线程。basave命令会fork一个子进程，然后该子进程会负责创建RDB文件，而服务器进程会继续处理命令请求
快照时，数据能修改嘛？ Redis接住操作系统的写时复制技术（copy-on-write，COW）,在执行快照的同时，正常处理写操作。
虽然bgsave执行不会阻塞主线程，但是频繁执行全量快照也会带来性能开销。比如bgsave子进程需要通过fork操作从主线程创建出来，创建后不会阻塞主线程，但是创建过程是会阻塞主线程的。可以做增量快照。
-
RDB的优点：与AOF相比，恢复大数据集的时候会更快，它适合大规模的数据恢复场景，如备份，全量复制等
-
缺点：没办法做到实时持久化/秒级持久化。
Redis4.0开始支持RDB和AOF的混合持久化，就是内存快照以一定频率执行，两次快照之间，再使用AOF记录这期间的所有命令操作。