【Redis】Redis持久化策略

策略

RDB => Redis DataBase 相当于定期的方式实现持久化
AOF => Append Only File 相当于实时的方式实现持久化

RDB

RDB定期的把我们Redis内存中的所有数据，都写入硬盘中，生成一个"快照"

Redis给内存中当前存储的这些数据，赶紧拍个照片，生成一个文件，存储在硬盘中~~

后续Redis一旦重启了，就可以根据刚才的"快照"就能把内存中的数据给恢复回来~
"定期"具体来说，又有两种方式：

1.手动触发.

程序员通过redis客户端，执行特定的命令，来触发快照生成

save

bgsave

2.自动触发.

在Redis配置文件中，设置一下，让Redis每隔多长时间/每产生多少次修改就触发。
save：执行save的时候，redis就会全力以赴的进行"快照生成"操作，此时就会阻塞redis的其他客户端的命令~导致类似于keys*的效果

一般不建议使用save

bgsave：bg=>background 不会影响Redis服务器处理其他客户端的请求和命令

Redis咋做到的？是不是搞了个多线程啥的？

并非如此！！

并发编程的场景.此处redis使用的是"多进程"的方式，来完成的并发编程，来完成的bgsave的实现。

bgsave执行流程

1.判断当前是否存在其他正在工作的子进程。

比如现在已经有一个子进程正在执行bgsave，此时就直接把当前的bgsave返回~

2.如果没有其他的工作子进程，就通过fork这样的系统调用创建一个子进程来~

fork是linux系统提供的一个创建子进程的api(系统调用)

fork创建子进程，简单粗暴，直接把当前的进程(父进程)复制一份，作为子进程~

一旦复制完成了，父子进程就是两个独立的进程，就各自执行各自的了~~

3.子进程负责进行写文件，生成快照的过程.

父进程继续接收客户端的请求，继续正常提供服务.

4.子进程完成整体的持久化过程之后，就会通知父进程，干完了，父进程就会更新一些统计信息，子进程就可以结束销毁了。

RDB效果演示

rdb文件中的数据，不是你这边插入了数据，就会立即更新的！！

1.手动执行save&bgsave触发一次快照

由于我们的数据比较少，执行bgsave瞬间就完成了，立即查看应该就是有结果的.如果以后我们接触的数据多了，执行bgsave就可能需要消耗一定的时间，立即查看不一定就是生成完毕了~

通过上述操作，就可以看到，redis服务器在重新启动的时候，加载了rdb文件的内容，恢复了内存中之前的状态。
2.插入新的key，不手动执行bgsave

发现没有，重新启动redis服务器

发现就有了，redis生成快照操作，不仅仅是手动执行命令才触发，也可以自动触发！！

1)通过刚才配置文件中save执行M时间内，修改N次

2)通过shutdown命令(redis里的一个命令)关闭redis服务器，也会触发。

3)redis进行主从复制的时候，主节点也会自动生成rdb快照，然后把rdb快照文件内容传输给从节点

如果是通过正常流程重新启动redis服务器，此时redis服务器会在退出的时候，自动触发生成rdb操作，但是如果是异常重启(kill -9 或者服务器掉电)此时redis服务器来不及生成rdb，内存尚未保存到快照中的数据，就会随着重启而丢失~

3.bgsave操作流程是创建子进程，子进程完成持久化操作.
持久化会把数据写入新的文件中，然后使用新的文件替换旧的文件.

liunx文件系统.

文件系统典型的组织方式(ext4)主要是把整个文件系统分成了三个大的部分

1.超级块(放的是一些管理信息)

2.inode区(存放inode节点，每个文件都会分配一个inode数据结构，包含了文件的各种元数据)

3.block区，存放文件的数据内容了。
4.通过配置自动生成rdb快照

执行FLUSHALL也会清空rdb文件

5.如果把rdb文件，故意改坏了，会咋样？

手动的把rdb文件内容改坏.

然后一定是通过kill进程的方式，重新启动redis服务器.

如果通过service redis-server restart重启，就会在redis服务器退出的时候，重新生成rdb快照。

就把咱门刚才改坏了的文件给替换了~~

RDB优缺点

RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景，比如每6小时执行bgsave备份，并把RDB文件复制到远程机器或者文件系统中用于灾备。
Redis加载RDB恢复数据远远快于AOF的方式。
RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork创建子进程，属于重量级操作，频繁执行成本过高。
RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个RDB版本，兼容性可能有风险。