Redis持久化存储

REmote DIctionary Server(Redis) 是一个由 Salvatore Sanfilippo 写的 key-value 存储系统，是跨平台的非关系型数据库。

Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存、分布式、可选持久性的键值对(Key-Value)存储数据库，并提供多种语言的 API。

Redis 通常被称为数据结构服务器，因为值（value）可以是字符串(String)、哈希(Hash)、列表(list)、集合(sets)和有序集合(sorted sets)等类型。

为什么要做持久化存储?

持久化存储是将 Redis 存储在内存中的数据存储在硬盘中，实现数据的永久保存。我们都知道 Redis 是一个基于内存的 nosql 数据库，内存存储很容易造成数据的丢失，因为当服务器关机等一些异常情况都会导致存储在内存中的数据丢失。

持久化存储分类

在 Redis 中，持久化存储分为两种。一种是 aof 日志追加的方式，另外一种是 rdb 数据快照的方式。

RDB持久化存储

什么是RDB持久化存储

RDB持久化存储即是将redis存在内存中的数据以快照的形式保存在本地磁盘中。

.RDB持久化存储分为自动备份和手动备份

1.手动备份通过 save 命令和 bgsave 命令。save是同步阻塞，而 bgsave 是非阻塞(阻塞实际发生在 fork 的子进程中)。因此，在我们实际过程中大多是使用bgsave命令实现备份.

redis> SAVE
OK
redis> BGSAVE
Background saving started

2.自动备份
a.修改配置项 save m n即表示在 m 秒内执行了 n 次命令则进行备份.
b.当Redis 从服务器项主服务器发送复制请求时，主服务器则会使用 bgsave命令生成 rbd 文件，然后传输给从服务器.
c.当执行 debug reload 命令时也会使用 save 命令生成rdb文件.
d.当使用 shutdown 命令关掉服务时，如果没有启用 aof方式实现持久化则会采用bgsave的方式做持久化.同时shutdown后面可以加备份参数[nosave|save].

bgsave持久化存储实现原理

1.执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如果存在则直接返回.
2.父进程fork一个子进程(fork的过程中会造成阻塞的情况),这个过程可以使用info stats命令查看latest_fork_usec选项,查看最近一次fork操作小号的时间,单位是微秒.
3.父进程fork完之后,则会返回Background saving started信息提示,此时fork阻塞解除.
4.fork出的子进程开始根据父进程内存数据生成临时的快照文件，然后替换原文件.使用lastsave命令可以查看最后一次生成rdb的时间，对应info的rdb_last_savetime选项.
5.当备份完毕之后向父进程发送完成信息，具体可以见info Persistence下的rbd*选项.

RDB持久化的优势与劣势

优势:
1.文件实现的数据快照，全量备份，便于数据的传输.比如我们需要把A服务器上的备份文件传输到B服务器上面，直接将rdb文件拷贝即可.
2.文件采用压缩的二进制文件，当重启服务时加载数据文件，比aof方式更快.
劣势:
1.rbd采用加密的二进制格式存储文件，由于Redis各个版本之间的兼容性问题也导致rdb由版本兼容问题导致无法再其他的Redis版本中使用.
2.时效性差，容易造成数据的不完整性.因为rdb并不是实时备份，当某个时间段Redis服务出现异常，内存数据丢失，这段时间的数据是无法恢复的，因此易导致数据的丢失.
RDB文件常见的处理方式
1.当遇到磁盘写满情况，可以使用如下命令来切换存储磁盘

// dirName则是新的存储目录名(该方式同样适用于aof格式)
config set dir dirName

2.文件压缩处理，虽然对CPU具有消耗，但是减少体积的暂用，同时做文件传输(主从复制)也减少消耗.

// 修改压缩开启或关闭
config set rdbcompression yes|no

3.rbd备份文件损坏检测.可以使用redis-check-rdb工具检测rdb文件,该工具默认在/usr/local/bin/目录下面.

[root@syncd redis-data]# /usr/local/bin/redis-check-rdb ./6379-rdb.rdb 
[offset 0] Checking RDB file ./6379-rdb.rdb
[offset 26] AUX FIELD redis-ver = '5.0.3'
[offset 40] AUX FIELD redis-bits = '64'
[offset 52] AUX FIELD ctime = '1552061947'
[offset 67] AUX FIELD used-mem = '852984'
[offset 83] AUX FIELD aof-preamble = '0'
[offset 85] Selecting DB ID 0
[offset 105] Checksum OK
[offset 105] \o/ RDB looks OK! \o/
[info] 1 keys read
[info] 0 expires
[info] 0 already expired

AOF持久化存储

AOF持久化存储是什么

AOF持久化存储便是以日志的形式将redis存储在aof_buf缓冲区中的数据写入到磁盘中。简而言之，就是记录redis的操作日志，将redis执行过的命令记录下载，当我们需要数据恢复时，redis去重新执行一次日志文件中的命令.

如何配置持久化存储
// 将no改为yes，控制aof开启与否
appendonly no
// 控制aof文件名称，存储的目录便是dir配置项
appendfilename "appendonly.aof"
// 三种备份策略(三者只需要开启以一个即可)
# appendfsync always // 命令写入立即写入磁盘
appendfsync everysec // 每秒实现文件的同步，写入磁盘
# appendfsync no // 随机进行文件的同步,同步操作则交给操作系统来负责，通常时间是最长30s
AOF持久化存储实现原理

aof日志追加方式实现持久化存储，需要经历如下四个过程.命令写入->文件同步->文件重写->文件重载

1.redis命令写入，此时会将redis命令写入aof_buf换从区.
2.缓冲区中数据根据备份策略实现写入日志文件.
3.当aof的文件越来越庞大，会根据我们的配置策略来实现aof的重写，实现文件的压缩，减少体积.
4.当redis重新启动时，在去重写加载aof文件，达到数据恢复的目的.

命令写入

命令写入主要是将文件执行过的命令写入到日志文件中.并且日志文件尊徐文本协议格式，下面示例代码便是aof日志文件中存储的内容格式.

*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

aof采用的是文本协议格式。主要是原因根据资料提示，可以能使由于如下原因.
1.文本协议的兼容性好.前面我们提及到了rdb文件是进行二进制加密，可能不同版本之间会出现不兼容的情况，采用文本协议可以加避免该问题。同时文本协议也可以减少跨平台使用所带来的诸多问题.
2.可读性强.由于aof是将命令写入文件中，我们可以直接查看命令内容，同时也可以修改日志文件内容.
3.开启aof后，所有的文件文件都包含追加操作，直接采用文本协议，减少二次开销(这一点，个人不是很理解.因为我们的aof是保存的是命令，当我们再次去加载的时候，会去执行一次里面的命令，当文件大的时候应该是比较耗时的吧。如果没有做好文件重写策略，大量重复无效的命令执行，对于二进制加密的rdb格式，不需要再去转换，这一点确实可以减少二次开销).

文件写入

文件写入是将aof_buf缓冲区的命令写入到文件中.文件写入的策略有如下三种方式

配置项配置说明always命令写入到aof_buf缓冲区中之后立即调用系统的<font color='red'>fsync操作</font>同步到aof文件中，fsync完成后线程返回.everysec命令写入到aof_buf缓冲区后<font color='red'>每隔一秒</font>调用系统的<font color='red'>write操作</font>，write完成后线程返回.no命令写入aof_bug缓冲区后调用系统write操作，不对aof文件做fsync同步，同步硬盘操作由<font color='red'>系统操作</font>完成，时间一般最长为30s.

系统调用write和fsync说明：
·write操作会触发延迟写（ delayed write） 机制。 Linux在内核提供页缓冲区用来提高硬盘IO性能。 write操作在写入系统缓冲区后直接返回。 同步硬盘操作依赖于系统调度机制， 例如： 缓冲区页空间写满或达到特定时间周期。 同步文件之前， 如果此时系统故障宕机， 缓冲区内数据将丢失.
·fsync针对单个文件操作（ 比如AOF文件） ， 做强制硬盘同步， fsync将阻塞直到写入硬盘完成后返回， 保证了数据持久化.
文件写入策略分析
配置为always时， 每次写入都要同步AOF文件， 在一般的SATA硬盘上， Redis只能支持大约几百TPS写入， 显然跟Redis高性能特性背道而驰，
不建议配置.
配置为no。由于操作系统每次同步AOF文件的周期不可控， 而且会加大每次同步硬盘的数据量， 虽然提升了性能， 但数据安全性无法保证.
配置为everysec。是建议的同步策略， 也是默认配置， 做到兼顾性能和数据安全性。 理论上只有在系统突然宕机的情况下丢失1秒的数据.

文件重载

1.为什么要文件做文件重载操作?
由于aof采用的是日志追加，我们redis命令不断的写入，aof文件的体积也也会不断的增加.因此redis引入了aof重写机制达到减小aof文件体积.<font color="blue">aof文件重写是把redis进程内的数据转换为写命令同步到新的aof文件的过程(这一点其实不是特别明白，文件重写不是针对aof文件文件做操作的吗？为什么这里是将redis进程内的数据转换为命令写入文件，这里的进程内的数据不是太明白，还有待深入研究.个人理解的就是将旧的aof文件内容根据重写策略，进行优化生成新的aof文件。).</font>
2.文件重载有什么好处?
文件重载主要优化的地方有如下三点。使用文件重载既可以减少文件的体积，同时去掉了一些无效的操作，可以加快文件重载效率.
a.将一些在进程内无效的数据不在写入新的文件.如过期的键.
b.去掉一些无效的命令.如del key1.
c.简化操作.如lpush list a,lpush list b.直接可以简化为lpush list a b.
3.文件重载由那些方式?
文件重载有自动触发机制和手动触发机制.
手动触发机制:直接使用bgrewriteaof命令即可.该命令在fork子进程的时候会发生阻塞.
自动触发机制:
auto-aof-rewrite-min-size:aof重写时文件最小的体积，默认的是64M.
auto-aof-rewrite-percentage:代表当前AOF文件空间（ aof_current_size） 和上一次重写后AOF文件空间（ aof_base_size） 的比值.

自动触发时机=aof_current_size>auto-aof-rewrite-minsize&&（ aof_current_size-aof_base_size） /aof_base_size>=auto-aof-rewritepercentage

其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看.
4.文件重载实现的原理是怎样的?