1、关于redis持久化问题，看看官网文档：
注：redis提供了多种不同方式的持久化选项：
RDB（即 redis database）持久化表现在特定的时间间隔内某一个时间点的快照。可以理解为，在指定时间间隔内将内存中的数据集快照写入磁盘，也就是常说的snapshot快照，它恢复时是将快照文件直接读入内存中。
AOF持久性地记录在服务器中的所有写操作命令，并且在服务器重新启动时执行这些操作命令。（关于AOF会在下一篇博文中介绍。）
补充说明:（redis设置连接数据库密码的操作命令）
注：使用 config set requirepass "密码" 可以设置或者修改连接密码，可以看到，设置连接密码后，立即生效，在下次操作数据库时，需要输入连接密码（auth 连接密码）
2、RDB 的详细说明：
Redis 首先会创建一个子程序（fork）来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束后，在用这个临时文件替换上次持久化好的文件。在整个过程中，主进程是不会进行任何IO操作的，这就确保了极高的性能。
如果需要进行大规模数据的恢复，且对于数据恢复的完整行不是很乐观，那RDB方式需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能会丢失。
fork的作用： 复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
概念说了这么多，来看看操作:（注意要开两个终端分别操作）
a、在 redis.conf 配置信息 的那篇博文中已经说到过 save的问题，这里在补充说明一下。 SNAPSHOTTING
为快照，可以看到，当设置为 save "" ,是不进行快照的。（图示中被注释了）如果设置为 save 120 10，意味着在120秒钟内，如果有10个
key 被删除、修改或者新增，redis会自动把 DB 保存到磁盘中。
b、 可以看到，在 2分钟内，我保存了14个key,redis在2分钟后，自动在指定目录下生成一个 dump.rdb文件。
注意：（自己犯的一个错误）因为在 path 路径下配置了 redis ,所以在那一个目录中启动 redis 都是没有问题的。DB 默认保存的 文件名为 dump.rdb，它会被保存在你所启动 redis 后台服务器的目录下。如图示，如果在输入 su - 命令后启动，就直接在 /root 目录下。
c、这里进行数据的备份，将dump.rdb备份，改名为dump_db.rdb
d、然后在 redis 中进行清空操作，再关闭服务
注: 在操作中发现，fluahsall之后，dump.rdb的创建时间发生改变，也就是说，redis用一个空 dump.rdb 文件覆盖了源文件。
e、重新启动redis,使用 keys *,发现原数据并不存在。（也可以理解，在flushall之后，dump.rdb文件已经被覆盖，redis 从磁盘中读取到内存中的是一个空文档）。
f、再次关闭redis,使用 cp命令拷贝dump_db.rdb 覆盖 dump.rdb 文件,再次启动redis,发现数据已经存在。
注: 这里只找回了10 条数据，和配置文件中的 save 配置一致，也就是说，使用RDB在发生异常时，可能会导致在最后一次保存到磁盘中时数据可能会部分丢失。
附: 在执行 save 操作时，dump.rdb文件也会被覆盖。
bgsave 操作与 save 操作的区别在于:
save 时只管保存，其他不管，全部阻塞。
而basave,redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。使用lastsave 命令还可以获得最后成功执行快照的时间。
3、补充关于 RDB 在 redis.conf 配置文件上的相关信息:
a、Stop-writes-on-bgsave-error: 在 savebg操作失败时，停止写操作。如果配置为no，表示你不在乎数据的一致性或者有其他方式解决这一问题。
b、rdbcompression: 对于存储在磁盘中的快照，是否进行压缩保存。如果是，使用 LZF 算法进行压缩保存。如果你不想消耗 CPU 来进行此操作，可以关闭该功能。
c、rdbchecksum: 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭该功能。
4、RDB 性能总结:
优势: 1、适合大规模的数据恢复
2、对数据完整性和一致性要求不高
劣势: 1、在一定时间间隔做数据备份，如果redis意外荡机，就会丢失最后一次快照后的所有修改。
2、Fork的时候，内存中的数据被克隆了一遍，大致2倍的膨胀性需要考虑。