Redis---持久化

Redis是内存数据库，是把数据存储在内存中的，但是内存中的数据不是持久的，如果想要做到持久，那么就需要让redis将数据存储到硬盘上。

Redis持久化有两种策略：

RDB ==> Redis DataBase RDB机制采取的是定期备份
AOF ==> Append Only File AOF机制采取的是实时备份

接下来将好好说说这两种策略~

RDB

RDB会定期地将Redis中的数据生成一份快照，接着将这份快照保存到硬盘中。后续Redis重启了，就会读取这份快照，将数据恢复回来。

定期具体点，又分为两种方式：1.手动触发 2.自动触发

手动触发

用户通过redis客户端，执行特定的命令，手动地触发快照生成。

save：执行save的时候，redis会全力以赴地进行“快照生成”操作，此时会阻塞redis的其它客户端的命令，导致类似keys *的后果，基本不采取。
bgsave：Redis进程执行fork操作创建出子进程，RDB持久化过程交由子进程去操作，完成后自动结束。阻塞只发生在fork阶段、一般时间很短。

自动触发

1.在redis的配置文件中，设置save配置。如”save m n“表示m秒内，数据集发生了n次修改，自动RDB持久化。

2.也可以从节点进行全量复制操作时，主节点自动进行RDB持久化，随后将RDB文件内容发送给从结点。

3.还可以执行shutdown命令，关闭redis，执行RDB持久化。

bgsave流程说明

1.执行bgsave命令后，redis父进程首先会判断当前是否存在正在执行的子进程，如果有，则返回。

2.如果没有，则通过fork创建子进程，在创建子进程时会阻塞父进程。创建完成后，bgsave会返回“background saving started”信息，不再阻塞父进程，父进程接着下面的操作。

3.子进程创建出来后，会创建RDB文件，由于子进程继承了父进程的内存、文件描述符等等，因此可以根据父进程中的内存的数据生成快照，并且对原有的RDB文件进行替换，结束后发送信号通知父进程表示完成，接着子进程结束。

RDB文件

redis生成的RDB文件，是在redis的工作目录中的，可以在redis的配置文件中进行设置。生成的RDB文件为：dump.rdb

RDB为使用LZF算法，将数据进行压缩，并且以二进制的形式，保存在这个文件中。虽然压缩会消耗CPU资源，但是能节省不少空间。

在redis服务器启动的时候，如果dump.rdb文件被损坏，那么服务器会启动失败（使用RDB机制的情况下）。因此redis提供了RDB文件的检测工具：redis-check-dump。

dump.rdb文件始终只有一个：尽管进行多次的RDB持久化，RDB会把要快生成的快照数据先保存在一个临时文件中，等快照数据生成完毕，会删除原来的dump.rdb，生成新的dump.rdb。

RDB的优缺点

优点：

①RDB是一个压缩的二进制文件，代表着某个时间点中redis的内存中的数据，非常适用于备份，全量复制等场景。

②redis加载RDB数据比AOF数据快。

缺点：

①RDB没办法进行实时持久化，每次运行bgsave都需要创建子进程，执行成本高。

②RDB有多个版本，兼容性存在问题。

RDB最大的问题在于不能实时持久化，在两次生成快照期间，可能会由于某种因素导致redis服务器重启，从而导致数据丢失的问题。

AOF

AOF介绍

AOF提供的是实时的持久化，解决RDB不能持久化的问题。AOF类似于MySQL中的binlog，会将用户的每一个操作，记录在文件中。当redis服务器重启后，会读取AOF的文件来恢复数据。

在redis的配置文件中，将AOF机制启动：

启动后重启redis服务器，则开启aof，在工作目录（/var/lib/redis）中出现了appendonly.aof的文件，这个文件就是用于记录redis内存数据的文件。

AOF是一个文本文件：

AOF工作流程

AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）。

所有的写入（append）会追加到aof_buf缓冲区中，接着AOF会根据策略向硬盘做出同步操作。

如果AOF文件过大，需要进行重写（rewrite），进行压缩，节省空间。

当redis服务器启动时，会加载AOF文件进行数据的恢复。

AOF过程中为什么需要aof_buf这个缓冲区？

换句话说，引入AOF后，redis又要写内存又要写硬盘，这样效率会降低吗？其实不会，因为AOF机制，会先将数据放入aof_buf缓冲区中，数据累积到一定的量后，统一写入硬盘，降低IO次数，并且采取的是顺序写入，效率高。

同时，redis还提供了不同的缓冲区策略，给用户根据实际情况做出合理的选择。

文件同步

可配置值	说明
always	命令写入aof_buf后调用fsync同步，完成后返回。频率和数据可靠性最高，性能最低
everysec	命令写入aof_buf后只执行write操作，不进行fsync，每秒由同步线程进行fsync。频率和数据可靠性一般，性能一般
no	命令写入aof_buf后只执行write操作，由os控制fsync。频率和数据可靠性低，性能最高

系统调用write和fsync

write操作会在写入系统缓冲区后立即返回。

fsync只针对单个文件操作，强制硬盘同步，阻塞直到数据完全写入硬盘。

重写机制

随着AOF文件越来越大，它会影响到redis下次启动的时间，因为redis服务器在启动的时候，需要读取AOF文件，为了解决这个问题，AOF采取了重写机制。

AOF文件记录了用户的操作过程，但实际上，redis启动时读取AOF文件，只关心最终结果。比如用户A对同一个变量做了增加、修改、修改、修改操作，redis在读取时，只关心最后一次的修改，并不关心前面的操作如何。

因此，redis会对AOF文件进行整理，这个整理就是提出冗余的操作，合并一些操作。注意，这个过程，也是重新生成了一份AOF文件，AOF文件重写是把Redis进程内的数据转化为写命令同步到新的AOF文件。

AOF重写触发

AOF重写触发可以分为手动触发和自动触发。

手动触发：调用bgwriteaof命令
自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。

auto-aof-rewrite-min-size：表示触发从写时AOF最小文件大小，默认64MB.

uto-aof-rewrite-percentage：代表当前AOF占用大小相较于上次重写时增加的比例。

AOF重写流程

父进程通过fork创建子进程，子进程由于继承了父进程的内存、文件描述符等，可以把父进程fork前内存中的数据获取出来，以AOF的格式写入到一个新的AOF文件中。（内存中的数据，相当于整理后的数据了）。

在子进程写新aof文件的同时，父进程仍然不停地接收新的数据，并将这些数据同时写到aof_buf缓冲区和aof_rewrite_buf缓冲区中。aof_buf缓冲区的数据会被刷新到旧AOF文件中，而aof_rewrite_buf是用于子进程将新aof文件写完后，通知父进程，父进程再把这个缓冲区中的数据写入到新AOF文件中，最后用新AOF文件替换旧AOF文件。

父进程在重写的过程中，还在对旧AOF文件进行写入的目的：

在极端情况下，在子进程重写时服务器突然挂了，重启后，子进程内存的数据会丢失，新AOF文件的内容不完整，可以使用旧AOF文件来保证数据的完整性。

如果在执行bgwriteaof时，此时redis正在进行重写，那么就不执行了。

如果在执行bgwriteaof时，此时的redis正在生成RDB文件的快照时，会等待RDB文件生成完毕，再进行重写。