Redis学习总结—数据持久化

Redis 数据持久化是将内存中的数据保存到本地磁盘中，实现对数据的持久存储，假如在服务器发生故障后，也可以根据该持久化文件对数据进行恢复。
Redis 持久化操作有三种方式：RDB全量持久化、AOF增量持久化、RDB和AOF混合持久化。

RDB 全量持久化

RDB快照指内存中的数据在某一个时刻的状态记录。它的实现是类似照片记录的方式，把某一时刻的状态以文件的形式写到磁盘上，生成一个压缩的二进制文件，这个文件就是快照文件；即使机器宕机，这个快照文件也不会丢失，保证了数据的可靠性。恢复数据的时候，只需将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可。

触发方式

RDB是 redis 默认的持久化方式。触发方式有三种：save、bgsave、自动触发
1，save 触发方式在redis 主线程执行，所以在执行的时候会阻塞redis ，阻碍客户端其他命令的执行，直至RDB 过程结束为止。
2，bgsave 触发方式则是以异步的方式持久化数据，redis 会在后台执行fork操作创建出一个子进程，有子进程完成RDB操作，完成后自动结束。使用bgsave 触发持久化不会阻塞redis，但是因为fork 操作需要拷贝主线程的页表，当主线程内存越大时，页表相应也大，拷贝页表耗时长会阻塞主线程。
在持久化期间，Redis 执行读操作时，主线程和子进程互不影响，执行修改操作时，因为主线程和子进程共享内存数据，所以为了保证快照的完整性且允许主线程操作数据，redis 借助了操作系统的写时复制技术（copy on write），主线程修改数据时，会将这块数据复制一份，生成该数据的副本，主线程则直接在副本上进行修改，子进程就可以继续把原来的数据写入RDB文件。
3，自动化触发是通过配置文件完成的。在 redis.conf 文件中配置 save 参数触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，就会自动触发 bgsave。当我们不需要RDB 持久化时直接注释掉该参数即可。

save 900 1    #表示在900秒内，有1次修改操作时
save 300 10   #表示在300秒内，有10次修改操作时
save 60 10000 #表示在60秒内，有10000次修改操作时

另外，在这几种情况下也会发生RDB快照：
1，在主从复制时，从库全量复制同步主库数据时，主库会执行bgsave命令进行快照。
2，客户端在执行数据库清空命令 FLUSHALL 时，也会触发快照。
3，客户端在执行 shutdown 关闭 redis 时，也会触发快照。

实现步骤

1，客户端执行bgsave命令，redis主进程收到指令并判断此时是否在执行 bgrewriteaof(AOF重写)，如果此时正好在执行则bgsave直接返回，不fork子进程；如果没有执行 bgrewriteaof 则进入下一个阶段
2，子进程创建完成以后，bgsave 命令会返回“Background saving started”，此时标志着 redis 可以响应客户端请求了
3，子进程根据主进程的内存副本创建临时快照文件，当快照文件完成以后对原快照文件进行替换
4，操作完成后子进程发送信号给redis主进程，主进程更新统计信息，子进程退出。可以使用 info Persistence 命令查看持久化信息。

RDB 的优缺点

优点：
1，RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
2，生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作。
3，RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
缺点：
1，RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，阅读性差。
2，因为是 fork 的子进程复制数据的持久化，所以主线程修改内存数据时不会影响到子进程，但快照持久化期间修改的数据不会被保存，可能丢失较多数据。

AOF 增量持久化

AOF增量持久化就是redis将每一个收到的写命令都通过write函数追加到文件中，通俗来说就是日志记录。AOF 日志以文本的形式记录，为了避免额外的检查开销，redis 会先执行这些命令，待命令执行完成后再写回到AOF日志文件中。
AOF 默认是关闭的，通过redis.conf配置文件进行开启 appendonly yes ，或者直接使用 config set 修改，再用config rewrite同步到配置文件。config set 修改的好处就是不用重启redis，会直接生效。
有三种写回策略：

1. appendfsync always ：每次修改同步always，同步持久化 每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好。
2. appendfsync everysec ：每秒同步everysec，异步操作，每秒记录，如果一秒内宕机，有数据丢失，是避免影响主线程性能和避免数据丢失两者间的折中。
3. appendfsync no ：从不同步，一旦宕机，数据就会丢失。
   上述三种策略都会有可能造成数据丢失，因为AOF日志记录属于写后日志，在命令执行后，还未写回日志时发生宕机，恢复后该条命令执行会丢失。

AOF 重写

随着命令的执行，AOF文件会越来越大，带来一些性能问题
1，文件系统对文件大小的限制，无法保存过大的文件
2，文件太大，对文件追加命令记录的效率也会变低
3，如果发生宕机，AOF文件的恢复过程会很缓慢，影响 redis 的正常使用
为了解决上述问题，redis 实现了AOF 的重写机制

AOF 重写会根据当前键值对的最新状态，生成对应的写入命令，将其记录到新的AOF文件中。通过执行 bgrewriteaof 在后台 fork 一个子进程来完成，避免阻塞主线程降低redis的性能。
AOF 重写机制触发机制：自动和手动
自动触发通过 redis.conf 配置中的两个参数实现，auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积，默认为64MB。auto-aof-rewrite-percentage:代表当前AOF文件空间大小（aof_current_size）和上一次重写后AOF文件空间大小（aof_base_size）的比值，默认100。当上述两个参数同时满足时会触发AOF重写。
重写过程：
1，执行 bgrewriteaof 命令从主线程中fork出子进程，并将fork时的AOF文件数据写到一个临时AOF文件中
2，在重写过程中，redis会将写命令同时写到AOF缓冲区和重写缓冲区中，保证重写不丢失重写过程中的命令。
3，子进程重写完成后通知主线程，主线程将AOF重写缓冲区中的数据追加到子进程生成的AOF新文件中
4，redis 原子的将旧文件替换为新文件，标志AOF重写完成。开始将数据写入到新的AOF文件上
注意
1，执行重写时如果发现有进程正在执行重写，那么直接返回。如果有进程正在执行BGSAVE，那么会等BGSAVE执行完成后再执行重写。
2，Redis执行重写时会fork一个进程进行，其开销和RDB一样
3，重写过程不影响原有的AOF过程，write，save操作都不影响（写时复制）
4，重写过程中有几个时刻会阻塞主线程： 在fork子进程时，将重写缓冲区的数据写到磁盘上时，使用新AOF文件替换旧文件时
5，重复或无效的命令不会写入新文件
6，过期的数据也不会再写入新文件
7，多个命令能合并成一条命令时会对其优化合作为一个命令写入新文件，例如“RPUSH list1 a RPUSH list1 b" 会合并为“RPUSH list1 a b”

AOF的优缺点

优点：
1，AOF只是追加写日志文件，对服务器性能影响较小，速度比RDB要快，消耗的内存较少。
2，AOF是基于redis通讯协议形成的命令追加方式，内容是文本形式的，兼容性高，阅读性较好。
缺点：
1，AOF生成的日志文件太大，需要不断AOF重写，进行瘦身。
2，由于AOF文件是文本文件，文件体积较大（相比RDB的二进制文件）。
3，AOF是重演命令式的恢复数据，速度会比RDB慢。

AOF 文件格式

AOF 文件是以行来划分，每行以\r\n结束。每一行都有一个消息头，消息头共分为5种分别如下:
（ + ）表示一个正确的状态信息，具体信息是当前行 + 后面的字符。
（ - ） 表示一个错误信息，具体信息是当前行 - 后面的字符。
（ * ）表示消息体总共有多少行，不包括当前行，* 后面是具体的行数。
（ $ ）表示下一行数据的长度，不包括换行符长度\r\n，$ 后面是对应的长度数。
（ : ）表示返回一个数值，: 后面是相应的数字节符。

混合持久化

混合持久化是Redis 4.0 新增加的功能，将 RDB 文件的内容和增量的 AOF 日志文件一起写入到AOF文件中。在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率大幅度提升。
混合持久化默认关闭的，通过 redis.conf 文件的 aof-use-rdb-preamble 参数控制，yes表示开启，no表示禁用，默认是禁用的，可以通过 config set 修改。

实现

混合持久化通过 bgrewriteaof 完成的，与AOF增量持久化重写不同的是当开启混合持久化后，fork 出的子进程会先将共享的内存副本全量的以RDB方式写入AOF文件，然后再将AOF重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主线程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换掉旧的的AOF文件。
新的AOF文件前半段是RDB格式的全量数据，后半段则是AOF格式的增量数据。

混合持久化的优缺点

优点：
混合持久化结合了RDB持久化 和 AOF 持久化的优点，由于大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存，数据更少丢失。

缺点：
兼容性差，因为在4.0之前的版本都不识别该AOF文件，同时由于前一部分是RDB格式数据，阅读性较差。