Redis rdb持久化
目录
一：Redis持久化
二：Rdb介绍
dump.rdb文件：
保存触发的方式：
自动保存：
手动保存：
保存过程
阻塞保存：
非阻塞式保存：
三：优缺点
优点：
缺点：
一：Redis持久化
众所周知，redis是基于内存的高效数据库。而内存的其中的一个特点就是 断电失效，所以为了防止redis服务崩溃，机器断电等导致数据丢失。redis提供了两种持久化方式：RDB和AOF，今天我们来详细介绍 RDB方式持久化。
二：Rdb介绍
Rdb是redis的默认持久化方式，它实现持久化的方式是在特定时间点(可以自己设置)将内存中的redis数据以二进制压缩的方式存储到一个特定目录下的文件中，默认文件名为：dump.rdb；这个文件中保存了redis中所有的键值对数据。
dump.rdb文件：
1，我们先要找到这个文件的位置，它的路径保存在redis的配置文件中：/etc/redis/redis.conf。我们可以用下面的命令来查看路径
//用grep过滤信息 cat /etc/redis/redis.conf | grep dir运行该命令：
使用vi命令查看dump.rdb：
vi /var/lib/redis/dump.rdb
这里我们可以看出dump.rdb里面存储的是不可读的二进制文件。redis服务在启动的时候就会加载该文件中的内容来恢复数据。如果该文件损坏就会导致redis服务无法启动，我们可以通过redis-check-rdb命令来检查
redis-check-rdb /var/lib/redis/dump.rdb
如果文件损坏了要如何修复这里就不介绍了。
保存触发的方式：
我们现在知道了redis服务读取dump.rdb文件来恢复数据，那我们什么时候将数据写入到dump文件中呢？分为自动保存和手动保存。
自动保存：
redis服务的一个核心服务就是定时备份数据，它有许多备份策略存储在redis配置文件中：
cat /etc/redis/redis.conf | grep save #运行该命令
- save 900 1 : 900秒内有1次修改就保存一次
- save 300 10：300秒内有10次修改就保存一次
- save 60 10000：60秒内有10000次修改就保存一次
当然大家可以自己修改保存策略，至于这个高效策略就需要通过具体的业务来测试寻找了。而如果不需要自动保存的话可以删除这三条并且添加：save ""(空字符串)。
redis服务在"优雅的退出"(systemctl stop redis-server 或者redis自带的退出命令：redis-cli shutdown)的情况下会自动保存一次，"不优雅的退出"(kill -9 或者断电等)就不会触发。
手动保存：
连接上redis客户端后，我们可以运行save(阻塞式)和bgsave(非阻塞式)两个命令来保存
保存的具体过程我们下面再讲。
保存过程
保存分为阻塞式保存和非阻塞式。
阻塞保存：
阻塞式保存很好理解，redis是单线程的，直接往dump.rdb文件写入数据就好了。但是数据如果过大就会造成长时间阻塞，这不符合redis平常任务的短平快的特点，会影响redis的效率，所以一般不推荐使用。
非阻塞式保存：
redis是单线程的，所以不能通过多线程来实现后台功能，于是redis选择了多进程，其原理就是linux系统中的 fork() 来创建子进程并将任务交给子进程来实现，同时父进程继续提供redis服务。子进程会生成临时的dump.rdb文件并写入数据，生成完毕后会替换旧的dump文件，有效防止在修改dump文件时程序崩溃导致dump文件被破坏。
效率方面，因为父子进程共享数据和写时拷贝技术，效率并不会低，可以放心使用。
两种保存方式在启动前都会先检测是否已经在保存的过程中了，如果有的话会保存失败。
大家可能看不到文件被替换的过程，我们可以通过stat命令来验证文件被替换了，原理是不同的文件inode编号也不同
这里redis-cli shutdown就是一个bgsave的过程
三：优缺点
优点：
- rdb文件是二进制的，二进制格式紧凑，适合备份，数据转移，灾难恢复
- 加载快，计算机天生适合二进制，读取数据的速度远快于文本存储的AOF
缺点：
- 同样因为是二进制的，导致rdb文件和redis版本相关，不同的版本之间rdb文件可能会失效，这种场景下一般都是写一个服务将旧的内容一条条读取并插入新redis服务
- 无法实时持久化，在两个bgsave过程中如果服务宕机就会丢失这个时间内的数据，这在对于安全性要求极高的服务中是不可取的。
rdb和aof两中方式并不是完全独立的，很多场景rdb会被aof影响，大家可以先去找aof的博客看看，也可以等我下一篇博客。