Redis之RDB持久化方式
Redis 相对于 Memcache 等其他的缓存产品，有一个比较明显的优势就是 Redis 不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储, Redis 的另外一大优势——持久化。
由于 Redis 是一个内存数据库。所谓内存数据库，就是将数据库中的内容保存在内存中，这与传统的MySQL，Oracle等关系型数据库直接将内容保存到硬盘中相比，内存数据库的读写效率比传统数据库要快的多（内存的读写效率远远大于硬盘的读写效率）。但是保存在内存中也随之带来了一个缺点，一旦断电或者宕机，那么内存数据库中的数据将会全部丢失。
为了解决这个缺点，Redis提供了将内存数据持久化到硬盘，以及用持久化文件来恢复数据库数据的功能。Redis 支持两种形式的持久化，一种是RDB快照（snapshotting），另外一种是AOF（append-only-file）
持久化简单理解就是将内存的数据移动到硬盘中，它的存在是防止电脑突然断电或者故障时数据的丢失。持久化到硬盘中后，只要硬盘不坏，下次启动的时候就可以再次将持久化到硬盘的数据快速的加载到内存中去。当然为了防止硬盘的坏掉，也有另外一种技术来支持这种容错性，那就是主从复制。RDB & AOF介绍
- 1.RDB(默认) redis database
在指定时间间隔内，将内存中的数据作为一个快照文件(snapshot)写入到磁盘，读取的时候也是直接读取snapshot文 件到内存。 - 2.AOF Append Only File
以日志形式记录每个写操作，启动时通过日志恢复数据。
RDB配置
持久化时间策略
1 | save 900 1 |
说明：若不想用RDB方案，可以把 save "" 的注释打开，上面三个注释掉
RDB 核心规则配置 save <指定时间间隔><执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中去。官方出厂配置默认是 900秒内有一个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。
配置其实非常简单，这里说一下持久化的时间策略具体是什么意思。
save: 这里是用来配置出发redis的RDB持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如save m n。表示m秒内数据集存在n次修改时，自动触发。bgsave（手动触发RDB持久化命令）。
默认配置如下：
- save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
- save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
- save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存
当然如果你只是用Redis的缓存功能，不需要持久化，那么你可以注释掉所有的save行来停用保存功能。当然，也可以在save的最后一行写上：save “”
那么为什么需要配置这么多条规则呢？
因为Redis每个时段的读写请求肯定是不均衡的，为了平衡性能与数据安全，我们可以自由定制什么情况下出发备份。所以这里就是根据自身redis写入情况来进行合理配置。
出错是否继续写
1 | yes |
说明：默认值为yes。
默认情况下，如果RDB 快照被启用并且最后一个后台保存失败，redis将会停止接收写操作。这将使得用户很难意识到数据不会准确的持久化到硬盘中，另外将没有人会注意到一些灾难性的事情会发生。如果后台保存进程重新开始工作，将会自动允许写入。然而，如果你为redis服务和持久化有启用合适的监控，你可能希望禁用这个特征，以至于redis可以继续像往常一样的工作，即便是硬盘存在一些问题，权限等。
是否压缩文件
1 | rdbcompression yes |
说明：默认值为yes。
配置存储至本地数据库时是否压缩数据，默认为yes，redis采用LZF压缩方式，但会占用一点CPU的时间。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。关于压缩的配置rdbcompression yes,建议没有必须开启，毕竟redis本身就属于CPU密集型服务器，再开启压缩会带来更加多的CPU消耗，相比硬盘成本，CPU更值钱。
是否检验文件
1 | rdbchecksum yes |
说明：默认值是yes。
是否检验rdb文件；从rdb格式的第五个版本开始，在rdb文件的末尾会带上CRC的检验和。这更有利于文件的容错性，但是在保存rdb文件的时候，会有大概10%的性能损耗，所以如果你追求高性能，可以关闭这个配置。
快照文件名
1 | dbfilename dump.rdb |
说明：指定保存RDB快照的文件名
工作目录
注意：这里必须指明的是一个目录，不能是文件名
1 | dir ./ |
说明：工作目录；默认是和当前配置文件保存在同一目录。也就是说通过此配置文件中的save方式，当实际操作满足该配置形式时就会进行RDB持久化，将当前的存储快照保存在dir配置的目录中，文件名有dbfilename决定。
手动触发
手动触发Redis进行RDB持久化的命令有两种：
save
该命令会阻塞当前redis服务器，执行save命令期间，Redis不能处理其他命令，知道RDB过程完成为止。
虽然该命令对于内存比较大的实例会造成长时间的阻塞，这是致命的缺陷，为了解决此问题，Redis提供了第二种方式。bgsave
执行该命令时，redis会在后台异步进行快照操作，快照的同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。
基本上Redis内部所有的RDB操作都是采用bgsave命令。
ps: 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。
恢复数据
将备份文件(dump.rdb)移动到redis安装目录并启动服务即可，redis就会自动加载文件数据到内存中了。Redis服务器在载入RDB文件期间，会一直处于阻塞状态，知道载入工作完成为止。
获取redis的安装路径可以使用config get dir命令。
停止RDB持久化
有些情况下，我们只想要利用Redis的缓存功能，并不想使用Redis的持久化功能，那么这时候我们最好停掉RDB持久化。可以通过上面讲的在配置文件redis.conf中，注释掉所有的save行来停用保存功能，或者直接一个空字符串来实现停用：save ""也可以通过命令： redis-cli config set save "" .
优势与劣势
- 优势
- RDB是一个非常紧凑（compact）的文件，它保存了redis在某一个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
- 生成RDB文件的时候，Redis主进程会fork()一个子进程来处理所有的保存工作，主进程不需要进行任何磁盘IO操作。
- RDB在恢复大数据集时的速度比AOF的恢复速度要快。
- 劣势
- RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高（影响性能）。
- RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题（版本不兼容）。
- 在一定间隔时间做一个备份，所以如果redis意外down掉的话，就会丢失最后一次快照的所有修改（数据有丢失）.
部分参考：
https://www.cnblogs.com/ysocean/p/9074787.html
https://blog.csdn.net/suprezheng/article/details/90679790
博主：YSOcean
RDB持久化方式：https://www.cnblogs.com/ysocean/p/9114268.html
AOF持久化方式：https://www.cnblogs.com/ysocean/p/9114267.html
博主：阿飞云
RDB:https://blog.csdn.net/u010648555/article/details/73433717
AOF:https://blog.csdn.net/u010648555/article/details/73442336