Redis_RDB持久化
- 基于RDB的持久化方式会把当前内存中所有的redis键值对数据以快照的方式写入硬盘文件中，如果需要恢复数据，就把快照文件读到内存中。
- RDB快照文件是经压缩的二进制格式的文件，它的储存路径不仅可以在redis服务器启动前通过配置参数来设置，还可以在redis运行时通过命令来设置。
- 有两种方式可以触发rdb持久化机制
- 通过save和bgsave等命令手动触发
- redis服务器会根据redis.conf配置文件里设置的方式定期把内存数据写入快照
- 基于rdb的持久化方式比较适合备份和灾备场景，但rdb无法实现即时备份，即上次生成快照后的修改会丢失。
save和bgsave命令
- Redis客户端运行save命令后，Redis服务器会把当前内存里的数据写入快照文件，在写入的过程中会暂停执行其他命令，直到写完快照文件。
- 如果当前Redis内存数据很多，那么一旦执行save命令，服务器就会长时间暂停执行命令，造成大量连接阻塞，从而导致线上问题，所以一般在执行save命令时需要非常谨慎。
- 和save命令对应的是bgsave命令，这里bg的含义是background，即后台运行。当用户输入bgsave命令后，Redis服务器会创建一个新的进程，在该进程里把内存数据写入快照文件里，在写的过程中Redis服务器能继续执行其他来自客户端的命令。
- 如果要查看bgsave命令的结果，可以继续执行lastsave命令，该命令返回的是一个时间戳，表示最近一次把内存数据存入快照文件的时间，如果该时间和 bgsave命令的运行时间能对应上，则能说明bgsave命令成功执行。
RDB持久化实践
1.修改配置文件
在redis的redis.conf配置文件中，可以通过save参数配置生成的rdb快照的条件，具体代码如下：
save 600 1
save 300 100
save 60 1000
第一行：表示当在600秒内有一个或者一个以上的键被修改时就会生成快照
第二行：表示当在300秒内有大于或者等于100个键被修改时就会生成快照
第三行：表示当在60秒内有大于或者等于1000个键被修改时就会生成快照
注意：这三个条件是“或”的关系，即只要有一个条件被满足，就会生成快照，从中能看出，rdb持久化文件只是当条件满足后生成快照，所以无法即时保存当前状态的内存数据。也就是说，通过rdb恢复数据时，会丢失上次生成快照后更新的数据
同时，在redis.conf里加上如下两条描述快照文件名的配置：
dbfilename redis.rdb
2.重启redis
检查redis是否启动
ps -ef|grep redis
关闭redis
redis-cli -a 123456 shutdown
重启redis
redis-server redis.conf
3.操作redis
set name pp
查看是否生成redis.rdb文件
两种持久化方式对比
- AOF可以设置一秒写一次持久化文件，所以相对于RDB而言，这种方式能更好地追加内存数据，从而能更好地达到持久化的效果，而且AOF是以“在文件末尾追加”的方式写入数据，所以性能较好
- AOF持久化的文件一般会大于RDB快照，所以用AOF恢复数据时速度会比RDB要慢
- RDB的快照是二进制文件，所以一般比AOF要小，所以在恢复数据时占优势，而且通过bgsave等方式生成快照时，redis服务器会新建一个子进程，所以不会影响redis服务器继续命令执行
- 在实际项目当中可以同时使用这两种方式，当数据误删的情况时，可以用AOF持久化文件来恢复数据，在一般情况下，可以用RDB快照来恢复数据。