redis持久化

🚀我们知道redis是将数据存储在内存当中的，通常使用来作为关系型数据库的缓存使用的，以缓解当大量请求到来时关系型数据库的压力。
🚀既然数据是存储在内存中的，那么就意味着redis服务重启，redis所在机器重启就会导致数据丢失，所以redis中的数据也是需要持久化的。
🚀这篇文章主要介绍redis持久化方式的一种rdb，（redis database的缩写）。

rdb策略

🚀rdb这种方式会定期的将redis中的数据，写入到磁盘中，生成一个快照，默认为dump.rdb的文件，可以在 /etc/redis/redis.conf 配置文件中修改 dir选项进行配置。

触发时机

🚀rdb触发的方式有两种。

• 第一种是redis自动的，当满足多长时间内修改了多少次的条件后会自动触发一次rdb。
• 第二种是手动触发，用户通过redis客户端，使用save或者bgsave命令触发rdb。

自动触发

🚀在redis的配置文件中可以配置自动触发的条件，通常redis的配置文件的路径为：/etc/redis/redis.conf，其中的save选项就是rdb自动触发需要满足的条件。

save选项的格式为，save 多少秒内 多少次修改，只有两个条件都满足才会触发，也就是说只有在这么多秒内产生了这么多次修改才会自动触发一次rdb。
如果你想关闭自动触发rdb的功能，可以将save选项配置为 save “”。

🚀除此之外，当使用shutdown命令关闭redis服务的时候，也会自动触发rdb。
执行shutdown命令前：

执行shutdown命令后：


可以看到dump.rdb文件的时间已经改变，说明生成了新的rdb文件。

虽然这是一个二进制文件，但是我们可以看到刚刚存储进去的key1和key2。
🚀在主从复制的时候，主节点会自动生成rdb快照，然后把rdb快照文件传输给从节点。
🚀flushall会清空dump.rdb快照文件。


可以看出，刚才的key1和key2都已经不存在了。

手动触发

🚀在redis客户端中输入save指令，此时redis服务器会全力以赴的生成快照文件，因为redis服务器采用单线程的工作方式，全力以赴的生成快照文件就意味着阻塞了其他客户端的请求，所以通常使用save手动触发rdb的方式不是一种好的选择。
🚀通常手动触发rdb，都是采用bgsave的方式，（bg-background 后台的意思），使用bgsave触发rdb的时候，redis服务器并不会亲自的去生成rdb快照文件，而是启动了一个子进程去生成这个rdb快照文件。

bgsave

🚀bgsave实现持久化时的步骤：

• 判定是否已经有子进程在做持久化的工作，确保只有一个子进程进行持久化的工作。
• 如果没有子进程，那么就fork一个子进程。
• 子进程负责持久化生成rdb文件，父进程继续负责响应客户端请求。
• 子进程完成工作后通过信号通知父进程。

🚀rdb文件是一个二进制文件，是将内存中的数据以压缩的形式存储到了这个二进制文件中的。并且redis提供了检验rdb文件格式的工具—redis-check-rdb。

需要注意的是，老版本的redis生成的rdb文件，在新版本的redis中可能识别不了。
🚀bgsave生成dump.rdb文件是先生成一个临时的文件，然后将老的rdb文件删除，将临时文件改为rdb文件。使用save的时候，是redis服务器进程直接向dump.rdb文件中写入，不涉及文件的替换。
🚀可以看出生成rdb文件的成本是比较高的，所以rdb文件生成的不能太频繁，这也就导致了rdb快照中的数据与实际内存中的数据相比是存在偏差的。