面试笔记——Redis（双写一致、持久化）

双写一致

双写一致性： 当修改了数据库中的数据，也要更新缓存的数据，使缓存和数据库中的数据保持一致。
相关问题：使用Redis作为缓存，mysql的数据如何与Redis进行同步？——双写一致性问题
回答时，根据不同的业务背景，分为高要求一致场景和允许延迟一致场景。

高要求一致业务场景

策略一： 在进行写操作时采用延迟双删策略 ，过程如图：
在这里插入图片描述
在执行更新操作之前，先进行一次删除缓存操作（删除旧数据），等数据库修改之后，再进行一次删除缓存操作（确保删除旧数据），降低脏数据的出现。
延时删除：由于数据库一般采取的是主从模式，当主节点的数据发生改变时，需要一定的时间等待其他的从结点完成数据同步，因此需要延时删除缓存。因此，延时的度也不好控制，延时双删策略仍会存在脏数据的风险。

特点： 有脏数据风险，代码耦合性高

策略二： 采用互斥锁，如图所示：
在这里插入图片描述
由上图可见，无论是读、写操作都要进行加锁访问数据库，这会大大降低服务器的性能。但在实际应用中，存入缓存中的数据大都是读多写少型数据（若需要经常修改数据，不建议放入缓存，直接访问数据库效率更高），因此可以采用（由Redisson提供的）读写锁 进行控制。
共享锁：读锁readLock，加锁之后，其他线程可以共享读操作
排他锁：独占锁writeLock也叫，加锁之后，阻塞其他线程读写操作
如图：
在这里插入图片描述
特点： 保证了数据的强一致性，但性能低，适合高要求一致的业务场景。

允许延迟一致业务场景

策略一： 异步通知保证数据的最终一致性
在这里插入图片描述
当我们将修改数据写入到MySQL后，就会发送一条消息到MQ，在缓存服务模块监听MQ，最终更新缓存。该方式保证最终一致性的关键在于——保证MQ的可靠性。

策略二： 基于Canal（由阿里开源的数据库变更监听工具）的异步通知：
在这里插入图片描述
当有数据被写入数据库，会把数据库发生的变化记录到BINLOG（二进制日志）文件中（如DDL【数据定义语言】语句和DML【数据操纵语言】语句），但不包括数据查询语句（如，SELECT、SHOW）。当Canal监听到BINLOG发生变化，则会通知缓存进行数据更新。

持久化

持久化是指将数据保存在非易失性存储介质（如，磁盘、固态硬盘等），主要目的是保证数据的持久性，即使在系统系统关闭或重启之后，数据仍然能够被恢复访问。Redis采用了两种持久化方式——RDB和AOF，这两种方式可以分别或同时使用，以满足不同的需求。

RDB（Redis Database Backup file，Redis数据备份文件，也称为Redis数据快照）持久化：
- RDB持久化是通过将Redis的数据集快照写入磁盘来实现的。它将当前内存中的数据状态保存到一个二进制文件（称为RDB文件）中，以便在Redis重启时进行恢复。
- 命令执行：
  
  ps：对主进程进行数据快照时，会阻塞其他进程执行，所以一般使用bgsave命令对子进程进行RDB，以上是主动备份的方式——即需要程序员手动备份。Redis提供了自动触发RDB的机制，可以通过redis.conf进行设置，如下：
- RDB持久化通常用于数据备份和恢复，因为它可以在较短的时间内创建一个全量的数据快照。
- RDB持久化的缺点是可能会造成一定程度的数据丢失，因为它是周期性地生成快照，如果Redis服务器突然崩溃，可能会丢失最后一次快照后的所有数据变更。
AOF持久化（Append Only File）：
- AOF持久化记录了Redis服务器接收到的所有写操作命令，以追加的方式写入一个日志文件（称为AOF文件）中。（ps：AOF默认是关闭，我们需要修改配置文件redis.conf来开启AOP。）
```
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
```
  设置AOF的命令记录的频率：
```
# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
```
  一般在项目中采取everysec的方式。
  Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：
```
# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb 
```
- AOF持久化可以保证更高的数据完整性，因为它记录了每个写操作命令，可以通过重新执行这些命令来恢复数据。
- AOF持久化的缺点是日志文件可能会变得很大，因此Redis提供了一些压缩和重写机制来减小AOF文件的体积。

RDB的执行原理

采用bgsave方式：

快照生成：
- RDB持久化通过生成数据库的快照来保存数据。当满足一定条件时（例如在一定的时间间隔内，或者在达到一定的写入操作次数时），Redis会fork一个子进程，将当前内存中的数据集以及服务器状态保存到一个临时文件中。
写入临时文件：
- 在生成快照期间，Redis主进程会继续处理客户端的读写请求。而子进程则负责将数据库的快照写入到临时文件中，这个过程不会阻塞主进程的运行。
替换原有文件：
- 当子进程完成快照的生成后，Redis会用新生成的临时文件替换掉旧的RDB文件，从而完成持久化操作。在这个过程中，Redis会使用原子操作来确保数据的完整性。

在这里插入图片描述
在上图中，主进程通过页表与内存进行数据交互。当进行数据备份时，主进程会创建一个新的子进程来完成该项任务（创建一个子进程和复制页表的时间消耗很少，因此对主进程的影响也小）。在子进程中，仍然是通过从主进程中复制的页表来读取内存中的数据。在子进程进行数据备份时，主进程不会发生阻塞，因此主进程可能会进行写操作，为了避免出现脏数据，因此对主/子进程共享的区域进行了操作限制，在子进程备份期间，该区域只允许读操作。当主进程执行写操作时，则会拷贝一份数据，执行写操作（如，数据B）。当子进程完成数据快照猴，替换掉磁盘上的旧RDB文件，保存当前读取的数据为新的RDB文件

fork采用的是copy-on-write技术：

当主进程执行读操作时，访问共享内存；
当主进程执行写操作时，则会拷贝一份数据，执行写操作。

特点： 定时对整个内存做数据备份。

优点：

高效的备份和恢复：RDB持久化通过生成数据库的快照来保存数据，生成的快照文件通常比较紧凑，恢复速度快，适合用于数据备份和恢复。
适用于大规模数据：RDB持久化在生成快照时会fork一个子进程，生成快照的过程中，主进程可以继续处理客户端的读写请求，因此适用于大规模数据的场景。
易于理解和操作：RDB持久化生成的快照文件是一个二进制文件，相对于AOF持久化的操作日志文件来说，更容易理解和操作。
适用于灾难恢复：RDB持久化生成的快照文件可以存档在磁盘上，以备份的形式存储，可以用于灾难恢复和数据迁移。

缺点：

可能造成数据丢失：RDB持久化是周期性生成快照文件，因此在两次快照之间的数据变更可能会丢失，尤其是在Redis服务器突然崩溃时可能会丢失最后一次快照后的所有数据变更。
IO开销较大：生成快照文件需要将整个数据集写入磁盘，因此可能会造成一定的IO开销，影响系统的性能。
不适合频繁写入场景：由于生成快照需要将整个数据集写入磁盘，因此对于频繁写入的场景，RDB持久化可能会导致较大的性能开销。
不够实时：RDB持久化是基于时间间隔或写入操作次数触发的，因此无法做到实时保存数据，可能会有一定的数据延迟。

AOF执行原理

写入操作记录：
- 当Redis接收到写入操作（如SET、DEL等）时，它将相应的写操作以追加（Append）的方式记录到AOF文件中，即将操作命令追加到AOF文件的末尾。
数据恢复：
- 在Redis重启时，会读取AOF文件中的操作记录，并按顺序重新执行这些写操作命令，以重建数据集的状态。

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。
在这里插入图片描述
特点： 记录每次执行的写入操作命令。