一、redis为什么要做持久化
由于Redis是一种内存型数据库，即服务器在运行时，系统为其分配了一部分内存存储数据，一旦服务器挂了，或者突然宕机了，那么数据库里面的数据将会丢失，为了使服务器即使突然关机也能保存数据，必须通过持久化的方式将数据从内存保存到磁盘中。
二、redis持久化的两种方式：
RDB和AOF两种持久化方式。
RDB方式是通过快照方式完成的,当符合一定条件时Redis会自动将内存中的所有数据进行快照并且存储到硬盘上。进行快照的条件在配置文件中指定,有2个参数构成:时间和改动键的个数,当在指定时间内被更改的键的个数大于指定数值时就会进行快照。redis通过执行SAVE/BGSAVE命令，执行数据的备份，将redis当前的数据保存到*.rdb文件中，文件保存了所有的数据集合。
AOF是增量的持久化方式，服务器通过读取配置，在指定的时间里，追加redis写操作的命令到*.aof文件中。
三、实现RDB快照的两个命令：
save：
调用save命令时，Redis会执行同步保存，阻塞所有客户端，不再响应客户端发送的请求。save命令一般来说只用于没有足够内存执行BGSAVE命令，或者对于等待保存占用的时间不敏感时才会使用。调用SHUTDOWN命令关闭服务器时也会先执行一次SAVE命令。
bgSave：
1、将快照文件直接读到内存里；
2、Redis会单独创建（fork）一个子进程来进行持久化，先将系统最新操作redis数据的写入到一个临时文件中；
3、待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
四、使用bgSave持久化需要做的配置
在redis.conf配置文件中，有如下预制的条件
save 900 1 # 15分钟内至少有一个键被更改
save 300 10 # 5分钟内至少有10个键被更改
save 60 10000 # 1分钟内至少有10000个键被更改
（以上条件是或的关系）
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir ./1、save：
save后面需要加上两个数字，分别代表秒数和更改数。假如设置了save m n，就代表如果在经过m秒之后发生了至少n次更改，Redis就会自动执行一次BGSAVE命令。
save配置项可以同时存在多个，如果save太过频繁，会影响到Redis的性能，频率太低则会增加数据丢失的风险，所以建议根据需要对save项进行配置。如果移除所有的save配置项或者加上一项save “”，则自动保存功能会被关闭。
2、stop-writes-on-bgsave-error yes：
默认情况下，如果后台保存出错了，Redis会停止接受写操作。如果后台的保存进程重新开始工作，Redis也会自动恢复接受写操作。
这是一种比较简单粗暴的解决方式，通过这种方式可以显示地提醒维护者Redis出现了故障，但也会导致在故障被修复前Redis都没办法提供完整的服务。如果设置了stop-writes-on-bgsave-error为no，则Redis出问题的时候也可以照常工作，不过这就需要更细致地监控Redis服务器的变化。
3、rdbcompression yes：
rdbcompression配置项设置是否对RDB文件进行压缩。如果将rdbcompression设置为no的话RDB文件保存的速度会快一些，但是保存下来的文件也会相应地变大。Redis使用LZF压缩RDB文件。
rdbchecksum yes ：rdbchecksum配置项控制Redis是否使用循环冗余检验。如果启用循环冗余检验，可以保证文件的完整性，但是进行文件保存和加载时会损失10%左右的性能，如果追求最大性能可以考虑把这一项关闭。Redis使用的是CRC64。
4、dbfilename dump.rdb ：
dbfilename配置RDB文件的名字，我们也可以修改它的名字；
默认RDB方式保存的是dump.rdb文件，恢复也是识别的是dump.rdb
5、dir：
配置RDB文件保存的路径。AOF产生的文件也会被保存到这个路径下面。这个路径也是可以修改的。
五、测试
1、 为了更快看见效果，我添加了 save 1 1，1秒内，有1次键值更改，就进行快照。
保存，重启redis后配置文件生效。
2、修改key值；执行“shutdown”命令，模拟宕机；重启redis，get key，查看我们修改的值是否还在。
重启服务，连接redis后，有我们保存的值。
而且，RDB是Redis默认的持久化方式。我们在日常使用redis时，可以打开看一下它的redis.conf配置文件，里面已经配置了rdb持久化。