该命令在前面讲过，会清除redis在内存中的所有数据。执行该命令后，只要redis中配置的快照规则不为空，也就是save 的规则存在。redis就会执行一次快照操作。不管规则是什么样的都会执行。如果没有定义快照规则，就不会执行快照操作。
执行复制(replication)时该操作主要是在主从模式下，redis会在复制初始化时进行自动快照。这个会在后面讲到；
这里只需要了解当执行复制操作时，即时没有定义自动快照规则，并且没有手动执行过快照操作，它仍然会生成RDB快照文件。
RDB数据恢复演示准备初始数据
redis> set k1 1 redis> set k2 2 redis> set k3 3 redis> set k4 4 redis> set k5 5
通过shutdown命令关闭触发save
redis> shutdown
备份dump.rdb文件(用来后续恢复)
cp dump.rdb dump.rdb.bak
接着再启动redis-server(systemctl restart redis_6379)，通过keys命令查看，发现数据还在
keys *模拟数据丢失
执行flushall
redis> flushall
shutdown(重新生成没有数据的快照，用来模拟后续的数据恢复)
redis> shutdown
再次启动redis, 通过keys 命令查看，此时rdb中没有任何数据。
恢复之前备份的rdb文件（之前保存了数据的rdb快照）
mv dump.rdb.bak dump.rdb
再次重启redis，可以看到之前快照保存的数据
keys * RDB文件的优势和劣势一、优势
1.RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集，这种文件非常适合用于进行备份和灾难恢复。
2.生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
3.RDB 在恢复大数据集时的速度比AOF的恢复速度要快。
二、劣势
1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，频繁执行成本过高
2、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照之后的所有修改（数据有丢失）。
如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化。
4.3.2 AOF模式AOF(Append Only File)：Redis 默认不开启。AOF采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改Redis数据的命令时，就会把命令写入到AOF文件中。
Redis 重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。
AOF配置开关 # 开关 appendonly no /yes # 文件名 appendfilename "appendonly.aof"通过修改redis.conf重启redis之后：systemctl restart redis_6379。
再次运行redis的相关操作命令，会发现在指定的dir目录下生成appendonly.aof文件，通过vim查看该文件内容如下
*2 $6 SELECT $1 0 *3 $3 set $4 name $3 mic *3 $3 set $4 name $3 123 AOF配置相关问题解答问题1：数据都是实时持久化到磁盘吗？
虽然每次执行更改Redis数据库内容的操作时，AOF都会将命令记录在AOF文件中，但是事实上，由于操作系统的缓存机制，数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。在默认情况下系统每30秒会执行一次同步操作。以便将硬盘缓存中的内容真正地写入硬盘。
在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。一般来说能够启用AOF的前提是业务场景不能容忍这样的数据损失，这个时候就需要Redis在写入AOF文件后主动要求系统将缓存内容同步到硬盘中。在redis.conf中通过如下配置来设置同步机制。
参数 说明appendfsync everysec AOF持久化策略（硬盘缓存到磁盘），默认everysec
1 no 表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；
2 always 表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低；
3 everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。
问题2：文件越来越大，怎么办？