redis持久化-归纳

部分参考地址：
        较详细：https://baijiahao.baidu.com/s?id=1654694618189745916
        简明扼要：https://blog.csdn.net/qq_39291929/article/details/103436742
        很全：https://www.cnblogs.com/naci/p/3824815.html
        aof重写机制详解：https://blog.csdn.net/hezhiqiang1314/article/details/69396887

---

持久化流程 
1. 客户端向服务端发送"写"操作请求（此时，数据存在于客户端内存中） 
2. 数据库服务端接收写请求（此时，数据存在与服务端内存中） 
3. 服务端调用write（write是个系统的调用），将数据向磁盘上写（此时，数据存在于系统内存的缓冲区） 
4. 对系统进行操作，将缓冲区中的数据，写入磁盘控制器（此时，数据存在于磁盘缓存中） 
5. 磁盘控制器将数据写到磁盘的物理介质上（此时，数据真正存在于物理磁盘上了）

---

持久化方式：

1：RDB（redis database）

快照:每隔指定时间，将所有数据进行拍照保存(相对耗时)，redis默认的持久化策略，二进制文件保存，默认文件名dump.rdb。

触发方式：

1. 客户端发送指令 save：会阻塞当前redis服务器，执行save命令期间，redis不饿能处理其他命令，直到rdb过程结束执行完成后， 如果发现存在就得rdb文件，则用新的替换掉旧的。（若数据量大，则此方式不可取）
2. 客户端发送指令 bgsave(background save)：会在后台进行异步的快照操作，保证了在快照操作的同时，还可以响应客户端请求。
具体操作：redis进程执行fork操作，创建子进程，持久化操作由子进程负责，完成后自动结束。 也会发生阻塞，但时间很短。基本上redis内部的所有rdb操作都是bgsave命令。快照执行期间，主进程修改的数据不会被保存
3. 自动触发（配置redis.conf文件，默认使用bgsave命令）
- 文件内搜索save：其中的 **save seconds changes**为触发快照的条件，即：当**seconds**秒内，数据被修改了**changes**次，就会触发rdb快照。
- 文件内搜索stop-writes-on-bgsave-error ：默认值为yes：当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了；
- 文件搜索rdbcompression ；默认值是yes。：对于存储到磁盘中的快照，可以设置是否进行压缩存储。
- 文件搜索rdbchecksum ：默认值是yes：在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
- 文件搜索dbfilename ： 设置快照的文件名，默认是 dump.rdb
- 文件搜索dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save 
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
# 默认三个都开启，不需要持久化的时候，就注释掉所有的save来停掉保存功能
save 900 1         # 900秒内，只要有1次变化，就执行
save 300 10        # 300秒内，只要有10次变化，就执行
save 60 10000      # 60秒内，只要有10000次变化，就执行

对比：
因为第三种方式是配置的，所以我们对前两种进行一个对比：

    ```
       命令       | save             | bgsave 
       io类型     | 同步              | 不同步 
       阻塞       | 是                | 仅在fork时阻塞 
       优点       | 不占内存           | 不会阻碍客户端请求
       缺点       | 会阻塞客户端的请求  | 需要fork，占用内存,可能会丢失fork期间主进程修改的数据
    ```

优劣：

* 恢复：直接读取持久化文件到内存中(恢复大数据时，速度很快)

* 优势：
1. rdb文件只有一个，存储的是内存数据的二进制序列化形式，且文件紧凑，体量较小（文件不大），全量备份，非常适用于备份和灾难恢复
2. 生成rdb文件时，单独fork一个进程来执行保存操作，主进程不进行任何io，并可同时接受前台的请求
3. 恢复大数据集时速度更快

* 劣势：
当进行快照持久化时，主进程单独fork了一个 子进程 专门负责快照持久化，子进程会拥有主进程的内存数据，主进程修改内存时， 子进程不会反应出来，所以在快照持久化期间主进程修改的数据不会被保存，可能丢失数据。

2.AOF(appendonly.aof)

* 增量追加：调用write函数进行文件使用增量追加（类似于日志模式）

* 触发方式：
    * （1）always(每有修改同步)：

        每当有一个“写”命令过来时，则通过write函数，直接保存命令本身到aof文件的末尾
    * （2）everysec(每秒同步)：

        异步操作，每秒记录 （如果一秒内宕机，有数据丢失）
    * （3）no(不同步)：从不同步
    ```
       命令       | always              | everysec
       优点       | 不丢数据             | --
       缺点       | io开销很大，一般的    |丢一秒数据
                  | sata盘只有击败tps 
    ```

* 文件重写：

触发：由系统判断是否满足重写条件，或客户端输入命令 bgrewriteaof

重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。

为了压缩此文件，官方给出了**bgrewriteaof**命令，将内存中的数据以命令的方式保存到临时文件中， 同时会fork出一个新进程来将文件重写 重写的过程中，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件（类似于快照） aof 持久化是通过保存被执行的写命令来记录数据库状态的，所以AOF文件的大小随着时间的流逝一定会越来越大； 越来越大的aof文件影响包括但不限于：对于Redis服务器，计算机的存储压力；AOF还原出数据库状态的时间增加；

为了解决AOF文件体积膨胀的问题，Redis提供了AOF重写功能：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件， 新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。
详情：https://blog.csdn.net/hezhiqiang1314/article/details/69396887

* 优点

1. 数据完整（每秒/每修改）
2. 几乎不阻塞主进程（仅在重写机制临近结束时，会有暂时性的阻塞）
3. 重写机制保证文件不会过大

* 缺点
1. 相比rdb模式，aof文件还是大了
2. io请求次数还是有点多的，所以速度相对rdb来说 ，无论是存储，还是恢复 还是慢的

如果同时开启了aof和rdb，则系统在恢复数据时，仅会执行aof