版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/qq_32447321/article/details/87275219
因为要重启机器,之前用docker run时，仅想做缓存用，未考虑要持久化；docker restart redis导致原key-value丢失；仅遗留几个key
然后就查看了一下redis默认的持久化策略
alexcn.xyz:6371> keys *
1) "alex"
2) "alex2"
alexcn.xyz:6371> CONFIG GET save
1) "save"
2) "3600 1 300 100 60 10000"于是乎：手动触发Redis进行RDB持久化的命令：
alexcn.xyz:6370> bgsave
Background saving started
alexcn.xyz:6371> save
OK
（选其一，区别下续）接下来备份其生成的默认dump.rdb文件(redis数据库)，并写入20个 keys
redis中确实存在了新添加20 keys;下图：
alexcn.xyz:6371> keys *
1) "alex_4"
2) "alex"
3) "alex_6"
4) "alex_7"
5) "alex_15"
6) "alex_14"
7) "alex_11"
8) "alex_19"
9) "alex_5"
10) "alex2"
11) "alex_8"
12) "alex_17"
13) "alex_3"
14) "alex_18"
15) "alex_2"
16) "alex_16"
17) "alex_10"
18) "alex_9"
19) "alex_12"
20) "alex_1"
21) "alex_0"
22) "alex_13"此时默认的RDB并未进行持久化策略 图1，stop服务将会丢失key;
此时stop并把之前备份的 dump.rdb放在load目录，redis中将会是只有最初备份的2个keys
alexcn.xyz:6371> keys *
1) "alex"
2) "alex2"总结如下：redis的RDB是根据持久化策略进行自动或手动配置的；redis重启后通过读取.rdb文件进行load数据。
ps:
手动触发Redis进行RDB持久化的命令有两种：
1、save
该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。
显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，Redis提供了第二种方式。
2、bgsave
执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。
基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
ps:执行执行 flushall 命令，也会产生dump.rdb文件，但里面是空的，无意义