一、持久化简介

面对写入时候，可能会出现一些意外的情况，比方说断电，这个时候就需要恢复数据。

所谓持久化，就是利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的机制。

持久化的目的：防止数据意外丢失，确保数据的安全性。

保存数据一般有两种形式：

• 数据快照（RDB）
• 将数据操作步骤记录下来，不是直接的数据，类似日志（AOF）

二、RDB

2.1 RDB启动的方式

2.1.1 save 命令及工作原理

手动执行一次保存操作。当前快照保存在*.rdb文件中。

save相关配置：

配置	说明
dbfilename dump.rdb	可以设置本地数据库文件名，默认dump.rdb
dir	存储.rdb文件的路径
rdbcompression yes	设置存储至本地数据库时是否需要压缩数据，默认yes，采用LRF压缩
rdbchecksum yes	设置是否需要进行RDB文件格式校验，该校验过程在读写文件过程都会进行， 通常设置默认开启，否则可能有数据损坏风险

save指令的工作原理：

redis是单线程工作的，当有一堆指令过来的时候，按照序列执行。

假如执行到save指令的时候，执行时间很长，那么会阻塞当前Redis服务器，直到当前RDB过程完成为止，又可能会造成长时间的阻塞，一般不建议线上使用。

2.1.2 bgsave命令及工作原理

问题：数据量过大的时候，单线程执行方式效率过低如何处理？

解决：bgsave 指令：手动启动后台保存操作，但不是立即执行

bgsave的工作原理：客户端发送指令给redis后，redis返回启动后台保存开始，然后自己调用fork函数生成子进程来完成这个保存操作，保存成功后返回消息给redis。

bgsave是对save阻塞做出的优化，redis内部所有涉及到RDB操作都采用bgsave的方式来完成。

bgsave还有一个配置需要关注下：

stop-writes-on-bgsave-error yes  -------意思是后台存储过程中如果出现错误现象，是否停止保存操作；通常建议开启。

2.1.3 自动执行--save配置

问题：前两种方式都是通过手工执行命令的方式，那能不能自动执行呢？如果可以，多久执行一次呢？因为不知道数据产生了多少变化。

解决：conf文件配置：save seconds changes

作用：满足限定时间范围内key的变化数量达到指定数量即进行持久化。如果指定时间没有达到指令数量超时了，会重新计时，这里也是快照的思想。

参数：seconds : 监控时间范围    changes：监控key变化量

举例：save 1000 1   1000秒有一个变化就保存

           save 60 1000  一分钟有1000个变化就保存

save配置的工作原理：

• save 配置在判断计数的时候，不进行数据比对的意思是就算对同一个key set了两次相同的值，也会被认为是两次，影响数量是2而不是1。
• save配置启动执行的是bgsave的操作。
• save配置需要根据实际业务来，频率过高或者过低都容易出现性能问题，结果可能是灾难性的。

2.1.4 几种方式的对比

由于save配置后台使用的也是bgsave，因此我们对比save和bgsave即可。

方式	save	bgsave
读写	同步	异步
阻塞客户端指令	是	否
额外消耗内存	否	是
启动新进程	否	是

 2.1.5 RDB的优缺点

优点：

• RDB是一个紧凑压缩的二进制文件，存储效率较高
• RDB内部存储的是redis在某个时间节点的数据快照，非常适合于数据备份，全量复制的场景
• RDB恢复数据的速度比AOF快很多
• 应用：服务器每X个小时执行bgsave备份，并将RDB文件拷贝到远程服务器中，用于灾难恢复

缺点：

• RDB无论是指令执行还是配置执行，都无法做到实时持久化，具有较大的可能性丢失数据
• bgsave指令每次都要fork操作创建子进程，要牺牲一些性能
• Redis众多版本中关于RDB文件格式可能不统一，有可能出现各个版本服务之间数据无法兼容的现象

这一篇就先到这里，下一篇来说AOF。