Redis数据持久化-AOF和RDB学习笔记(仅作记录)

曾经终败给现在 2021-10-29 15:26 93阅读 0赞

小白的学习笔记,如果有不对的地方请指出，随手会进行修改订正

redis 性能卓越的其中一个原因是它虽然是单线程,但是读写快,redis同时也是一个内存数据库,因为redis的很多操作都是基于内存来进行读写的,但是当数据库突然崩溃或者断电，重启之类的意料之外的事故，就会有丢失的数据  
所以redis 对此也有相应的处理措施

redis 提供了两种方式 RDB(数据内存快照) 和 AOF（追加写入到文件之中)

## RDB ##

--------------------

*  RDB方式就是在指定的时间间隔内把在内存之中的数据集写成二进制文件写入到磁盘之中，数据恢复的时候将快照文件直接读取到内存之中
 *  为了不影响上次保存的数据，redis没有使用直接在二进制文件中改写的方式，而是写入到一个临时文件之中,待持久化结束之后，才会把这个文件替换之前的文件
 *  对于RDB方式,redis会单独创建一个`子进程`来进行持久化，主进程是不会进行IO操作
 *  RDB 的`缺点`主要是可能会丢失数据，没有达到save的条件，而发生错误，则会丢失一部分的数据
 *  RDB一般适用于那些对于数据的完整性要求不高的地方.因为RDB要比AOF方式要来的高效，因为RDB都是一些二进制文件

--------------------

*  RDB一般是在redis重新启动之后自动载入，并且redis在载入rdb的时候,redis是阻塞状态，如果文件损坏的话，redis会启动失败
 *  RDB快照位置，会由配置文件中的dir指明，dbfilename指定
 *  RDB触发条件
 *  客户端执行命令save和bgsave会生成快照；
 *  根据配置文件save m n规则进行自动快照；
 *  主从复制时，从库全量复制同步主库数据，此时主库会执行bgsave命令进行快照；
 *  客户端执行数据库清空命令FLUSHALL时候，触发快照；
 *  客户端执行shutdown关闭redis时，触发快照；

其中bgsave 和save的区别就是　在后台进行save ,　主线程依旧可以进行响应客户端的命令,只是在fork的时间段内进行阻塞

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RyZWFtMDEzMF9f_size_16_color_FFFFFF_t_70]  
对上述过程描述：

*  客户端执行bgsave命令，redis主进程收到指令并判断此时是否在执行bgrewriteaof(AOF文件重新过程，后续会讲解)，如果此时正好在执行则bgsave直接返回，不fork子进程，如果没有执行bgrewriteaof重写AOF文件，则进入下一个阶段；(在这里处理的原因主要是防止两个进程并发写大量数据)
 *  主进程调用fork方法创建子进程，在创建过程中redis主进程阻塞，所以不能响应客户端请求；
 *  子进程创建完成以后，bgsave命令返回“Background saving started”，此时标志着redis可以响应客户端请求了；
 *  子进程根据主进程的内存副本创建临时快照文件，当快照文件完成以后对原快照文件进行替换；
 *  子进程发送信号给redis主进程完成快照操作，主进程更新统计信息（info Persistence可查看）,子进程退出；

--------------------

save m n  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RyZWFtMDEzMF9f_size_16_color_FFFFFF_t_70 1]  
这个在配置文件之中，save m , n 标志在 900 秒中，有多少键发生改变，会触发save

## FLUSHALL触发 ##

flushall命令用于清空数据库，请慎用，当我们使用了则表明我们需要对数据进行清空，那redis当然需要对快照文件也进行清空，所以会触发bgsave。

## shutdown触发 ##

shutdown 命令触发　redis关闭前把所有的数据保存下来

--------------------

## AOF ##

ＡＯＦ的出现就是为了改善RDB可能会丢失的数据，采用的是追加的方式，每次的写操作会追加到`文本文件`之中，为什么不记录读记录?主要因为读记录对于数据来说并没有什么影响

开启AOF  
默认情况下，redis是关闭了ＡＯＦ持久化，开启AOF配置之后为yes ,修改配置文件  
AOF持久化阶段:

追加写入  
redis 将每一条写命令以redis通讯协议添加到缓冲区aof\_buf ,这样的好处在于大量写请求情况之下，采用缓冲区暂存一部分命令随后根据策略一次性写入磁盘中使用fsync系统调用函数，从os层面直接写入到硬盘纸上

--------------------

*  appendfsync always，每次操作记录都同步到硬盘上，最低效，最安全。
 *  appendfsync everysec，每秒执行一次把操作记录同步到硬盘上。默认选项。
 *  appendfsync no，不执行fysnc调用，让操作系统自动操作把缓存数据写到硬盘上，不可靠，但最快。

其中appendonly.conf  
conf 格式解析

*  \*　，表示命令的参数个数，例如set a 1是三个参数，所以是\*3
 *  $，表示参数的字节数，例如set这个参数是三字节，所以是$3，key值a是一个字节，所以是$1
 *  无符号，表示是参数的数据，例如set,a,1就是具体的数据

但是随着不断的数据的追加，appendonly.conf 迟早会很大，这时候redis会有重组操作,进行重写，好比说五个的incr 命令 ,进行重写之后变化为set a 6,同时会进行日志重写

--------------------

AOF优点:  
1.AOF可以设置完全不同步，每秒同步  
２.AOF文件是一个值追加日志的文件，可以通过`redis-check-aof`工具修复这些问题  
3.如果AOF文件过大，Redis 会在后台重写aof文件，重写后让aof文件压缩到最小所需的指令集  
4.AOF文件是有序保存数据库的所有写入操作，易读，易分析。即使如果不小心误操作数据库，也很容易找出错误指令，恢复到某个数据节点。例如不小心FLUSHALL，可以非常容易恢复到执行命令之前。

缺点:  
1.在相同数据量之下，AOF的文件通常体积比RDB大，因为ＡＯＦ式存指令的，ＲＤＢ只是所有指令的结果快照

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RyZWFtMDEzMF9f_size_16_color_FFFFFF_t_70]: /images/20211029/e978355971f544578d597a276ae679e6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RyZWFtMDEzMF9f_size_16_color_FFFFFF_t_70 1]: /images/20211029/3489c0e0c2e144e2b314f03ae582fcf4.png