redis持久化存储详解

redis的持久化策略

首先来看下持久化的概念

---

持久化是将程序数据在持久状态和瞬时状态间转换的机制。通俗的讲，就是瞬时数据（比如内存中的数据，是不能永久保存的）持久化为持久数据（比如持久化至数据库中，能够长久保存）

---

类比地来说的话就是把内存里的数据存入类似磁盘可永久地进行保存

那redis有哪些形式能够进行持久化存储数据呢

RDB和AOF
接下来看下这两种形式到底是怎样实现持久化的吧

一， RDB

1，先看下其在官网给出的定义

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
1.1优点

RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些

1.2缺点

如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.
RDB
需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度

2，RDB执行原理

那看完了官网对其的介绍，接下来看下RDB的执行原理究竟是怎样一回事

首先执行该bgsave时就会来判断是否含有子进程正在执行RDB或AOF操作文件 若有则结束
未fork子进程则fork（复制一个与当前的线程一样的线程作为原来线程的子线程来）出子线程 （这时会造成阻塞问题但若执行完fork指令有了一个子线程则不会再阻塞）
然后再会来根据内存里的快照生成RDB文件且会替换调原有的RDB文件且会进行二进制的压缩

3，触发

首先RDB有手动触发和自动触发两种青况

先看下手动触发

手动触发需要在控制台打出bgsave或者save指令 而bgsave指令的执行不回干扰到Redis主线程的任务执行
save指令的执行会首先停止主线程任务的执行 等把RDB文件持久化完成之后才会再执行主线程的任务
就好比 bgsave是在写作业的同时（Redis主线程）泡了一杯水（RDB） 相互不会受到干扰
而save是要在学习完一个新的知识（Redis主线程）才能完成老师步置有关的作业（RDB），只有在把新学的只识学会了之后才能再开始完成作业

再看下自动触发
首先看下其触发时机

1，在redis配置文件中设置了save的配置，
2，在主从复制的时候 当从节点做全量复制时，主节点会自动执行bgsave操作，并且把生成的RDB文件发送给从节点。
3，在debug reload，
4，执行shutdown

二，AOF

1，先看下其在官网给出的定义

AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

1.1优点

使用AOF 会让你的Redis更加耐久:
你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF
文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF
文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF
文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。 AOF
文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂，
对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL
命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ，
就可以将数据集恢复到 FLUSHALL 执行之前的状态。

1.2缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB
在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快，
即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）

2，AOF执行原理

首先在所有的写的命令时都会把这些命令存储进AOF缓冲区
再会跟据不同的形式（always、 no、
eversec）来决定要再啥时候把数据同步到AOF文件区 然后把AOF里的文件给定期在重写将文件进行压缩减小存储空间
在数据在需要恢复的时候将文件执行就能够完成持久化

3，触发

1，手动触发
bgrewriteaof指令
2，自动配置
再Redis的配置文件里找到auto-aof-rewrite-min-size（执行AOF操作时的文件大小的最小值）及auto-aof-rewrite-percentage（这次重写AOF文件的大小值和上次重写文件的比值）