【Redis】双写一致性及数据持久化

1 双写一致性

1.1 概念

当修改了数据库的数据，同时要更新保存缓存的数据，缓存与数据库的数据要保持一致

1.2 相关操作

读操作：缓存命中，直接返回；缓存未命中，查询数据库，写入缓存，设置超时时间

写操作：延时双删

先删除缓存还是先删除数据库呢？

答案是二者都有可能造成脏数据

那么为什么删除两次缓存呢？

答案是为了尽量避免脏数据，但仍有风险

那如何保持强一致性呢？

1.2.1 分布式锁

但是会发现，如此会大大降低性能，那么如何优化呢？

首先，我们知道，存入缓存的数据都是读多写少

因此，我们可以加两个锁：

共享锁：读锁readLock，加锁后，其他线程可共享读操作

排他锁：独占锁writeLock，加锁后阻塞其他线程读写操作

虽然优化了，但不难发现，效率仍然不高，适合要求数据强一致性的

1.2.2 最终一致性

在不要求数据强一致时，也可以通过最终一致来保证数据最终的准确一致

我们可以通过异步通知来实现数据的最终一致性，下面时两种实现方案

1.2.2.1 基于MQ的异步通知

此方法需保证MQ的可靠性

1.2.2.2 基于canal的异步通知

binlog:二进制日志，记录所有的DDL（数据定义语言）和DML（数据操作语言）语句，但不包括SELECT，SHOW语句

以上两种方案性能较高，能够保证数据的最终一致

2 数据持久化

2.1 概念

数据持久化（Data Persistence）是指将内存中的临时数据转换为存储设备中的永久数据的过程，核心目的是避免数据因程序关闭、设备断电、系统崩溃等情况丢失，确保数据能够长期保存并在后续被再次读取和使用。

Redis中提供了两种数据持久化方式：RDB和AOF

2.2 RDB

RDB（Redis Database Backup file）即Redis数据备份文件，也称作Redis数据快照。

简单说就是将内存中的所有数据都记录到磁盘中，当Redis发生故障重启后，从磁盘读取快照文件恢复数据。

执行原理：bgsave操作开始时会fork主进程得到子进程，子进程共享主进程的内容数据，完成后读取内存数据并写入到RDB文件。

由于Redis无法直接操作物理内存，所以通过页表来进行操作

页表：记录物理地址和虚拟地址的映射关系

这时可能会想到子进程进行读操作的时候主进程能否进行写操作呢

这就涉及到fork采用的copy-on-write技术了：

主进程进行读操作时，访问共享内存

主进程进行写操作时，则会拷贝一份备份文件进行操作

2.3 AOF

AOF（Append Only File）即只追加文件，是 Redis 数据库用于实现数据持久化的一种机制。

Redis处理的每一写命令都会记录到AOF文件中

AOF时默认关闭的，需要修改redis.conf配置文件来开启AOF：

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配：AOF的命令记录的频率也可以通过redis.conf文件来配：

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb

2.4 RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。