Redis系列之持久化与缓存淘汰（六）

目录

RDB（Redis Database）

AOF（Append Only File）

缓存淘汰策略

---

RDB（Redis Database）

RDB持久化的方式是在一定的时间间隔后，将数据快照写入磁盘，恢复时是把磁盘中的快照文件读到内存中。

详细步骤：

Redis在执行RDB持久化时，会先创建（fork）出一个子进程，子进程负责把该时刻的数据快照写入一个临时文件temp中，写完后将temp文件替换掉原先的快照文件dump.rdb。整个过程主进程不涉及任何io操作，所以性能非常高，不过这种方式最后一次持久化后的数据可能会丢失。

Fork

 fork出的子进程开始并不会独享一份物理空间，而是先共享父进程使用的那一片内存页，然后“写时复制”，并且此时的父子进程都是只读状态。

什么是linux写时复制技术？当有写操作时，会触发缺页异常（内存最小管理单元--页），在这个异常处理函数中会有新开辟一块物理内存的操作，然后子进程使用新的物理空间，如下图：

 手动持久化

save命令可生成rdb文件，不过是阻塞的，不推荐用，一般是突发情况需要持久化时就去使用save手动保存数据。

bgsave推荐使用，Redis在后台异步进行快照操作，与此同时Redis可以响应客户端其它请求。（fork一个子进程去进行数据备份，父进程响应客户端请求），如果直接让父进程去持久化就会阻塞对命令的响应，注意父进程fork子进程的这一刻是会阻塞的，只是比较短暂。

自动持久化

默认持久化规则：

save 900 1       （15分钟变更一次）
save 300 10     （5分钟变更10次）
save 60 10000  （1分钟变更1万次）

另外配置文件中有关于文件是否压缩的配置 rdbcompression yes ，建议不压缩，相比于硬盘成本，还是选择性能更好。

缺点：

fork的时候内存中的数据会被克隆一份，可能会多出大约1倍的空间需要考虑到，并且如果数据量大，写时拷贝技术会比较消耗性能。另外最后一次持久化后的数据由于服务器意外宕机了也会丢失。

AOF（Append Only File）

是指以日志形式增量记录写入操作（把每个写操作记录下来，恢复时把这些写操作全部执行一遍）。

详细流程如下：

1. 每一个写操作被记录到aof缓冲区中。

2. aof缓冲区根据设置的同步策略（每分钟一次、每秒一次、每次、os来决定（不可控）...）将aof缓冲区中的写操作写入aof文件。

3. 当aof文件大小超过某一预设值即出发rewrite操作（对应的命令是bgwriteaof）（也可手动触发），对aof文件进行压缩。

4. Redis启动时会加载aof文件恢复数据。

这里的rewrite怎么理解？

 rewrite_buf用于确保新命令不丢。

aof持久化是不断地往aof文件后面追加新的写命令，为了防止文件越来越大，需要对aof文件进行内容压缩，当文件大小超过指定阈值就会触发。重写过程也是fork一条子进程（先写入临时文件再覆盖掉原来的aof文件）。 Redis4.0后的重写是把rdb文件的旧数据以二进制的方式添加到aof文件头部来替代原先的流水账操作。

重写并不会去分析旧文件哪些命令是没用的，而是直接看内存中有哪些数据，比如name 1这个数据没了那么有关他的操作就不用记了。

何时触发重写？

如果已经在aof了，那么直接返回，如果bgsave正在执行那么就推迟执行

当aof文件大小达到之前的两倍并且大于默认的64M就触发重写。比如到了70M重写降为50M，那么下次要到达100M才重写（一般认为64M太小了，可以设置为5G）。

优点：数据安全性更高，且aof文件可读性更好，可以处理误操作。

缺点：相比于rdb来说需要更多的磁盘空间，有一定的性能压力，恢复时速度更慢并且可能会有bug。

那么实际使用时用哪个好呢？

如果对数据不敏感就只用RDB，否则两个一起用（都启用的情况下会已aof为主，但是不建议只开启aof，因为可能出现bug）。另外如果只是把redis当做缓存使用那么两个可以都不开启。

缓存淘汰策略

 

 

 

 

 高并发场景下，到底先更新缓存（Redis）还是先更新数据库（MySQL）的问题？_corlor_龙的博客-CSDN博客_redis先更新缓存还是先更新数据库

第一种方案：多线程情况下会出现数据不一致，线程A更新缓存，线程B更新缓存，B更新数据库，A更新数据库，此时缓存是B的值但数据库是A的值

方案2的问题和1差不多，A更新库、B更新库、B更新缓存、A更新缓存。

方案4其实在写操作快于读操作的情况下还是会有问题，但概率极低。