redis笔记3-持久化

数据库与缓存

作为数据库，我们都知道数据时绝对不能丢的。
作为缓存，数据可以丢吗？ 追根溯源来说，既然作为缓存，本身在使用的时候，也会设置过期时间，数据是可以丢失的。但数据的丢失，场景使用,尤其是电商等高并发场景中，也会造成无法估量的损失。

持久化机制

redis 提供了 两种 持久化机制：RDB和AOF。存储层分别对应了使用  **快照** 和 **日志**

RDB

根据一定的规则进行快照生成，具有时点性，存在一定的数据丢失（延迟），但 **数据恢复快**。

生成快照时机

save 不常用
bgsave. fork子进程 进程 备份
配置文件中 给出 bgsave的规则
save 900 1
save 300 10
save60 1000
dbfilename dump.rdb
dir /var/lib/redis/6379

fork()

为什么 Redis 快照使用子进程 · Why's THE Design?

copy-on-write

需要考虑的问题：
+ 内存中存储大量的数据，fork 是 拷贝内存空间会消耗大量的时间和资源，会导致程序一段时间的不可用
+ Redis 占用了 10G 的内存，而物理机或者虚拟机的资源上限只有 16G，在这时我们就无法对 Redis 中的数据进行持久化，也就是说 Redis 对机器上内存资源的最大利用率不能超过 50%；

解决方案
copy-on-write 相应的出现。
+ 在真正访问虚拟内存空间时，Kernel 会将虚拟内存映射到物理内存上，所以父子进程共享了物理上的内存空间；
+ 当父进程或者子进程对共享的内存进行修改时，共享的内存才会以页为单位进行拷贝，父进程会保留原有的物理空间，而子进程会使用拷贝后的新物理空间；

弊端

不支持 拉链， 只有一个 dump.rdb
丢失数据 相对对一些

ＡＯＦ

　记录　redis　的写操作记录到文件中。丢失数据少

持久化配置

redis 中， RDB 和AOF 可以同时开启，如果 开启了AOF，只会用 AOF恢复。
在 redis 4.0以后， AOF中包含了RDB内容， 并记录增量内容。

弊端

文件大小无线变大，并且 数据恢复慢。

重写

 4.0以前，删除抵消的命令合并重复的命令
 4.0以后，将老的数据RDB到aof文件中将增量的以指令的方式Append到AOF， 开启了混合模式，充分利用了 RDB的快，和 AOF的 全量特性。

相关配置

写操作会触发 IO，AOF 的相关配置

appendonly yes
appendfilename "appendonly.aof"

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

appendfsync always
appendfsync everysec
appendfsync no