• Redis持久化
    • Redis有两种持久化方案： ● RDB持久化 ● AOF持久化
      • RDB被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。
        • RDB持久化在四种情况下会执行：
          • ● 执行save命令（save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞）
          • ● 执行bgsave命令(这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。)
          • ● Redis停机时(会默认保存数据，进行持久化)
          • ● 触发RDB条件时（比如900秒内，如果至少有1个key被修改，则执行bgsave）
          • bgsave原理： bgsave开始时会fork主进程得到子进程(注意这里都是进程，而不是线程),子进程通过主进程复制过来的页表共享主进程的内存数据。然后把主进程的数据进行备份到磁盘。
          • fork采用的是copy-on-write技术：
            • ● 当主进程执行读操作时，访问共享内存(这里面的内存数据是只读的)；
            • ● 当主进程执行写操作时，则会对这个数据进行拷贝，然后对这份拷贝后的数据执行写操作，等到备份完成再同步到这个内存数据中去。
        • 在redis服务器启动时，会自动去读取之前存储的RDB文件加载数据到redis中
        • RDB的缺点是：RDB执行间隔长，两次RDB之间可能会有丢失数据的风险。
      • AOF是命令日志文件。Redis会把收到的每一个写命令都记录在AOF文件
        • Redis会在下面几种情况执行记录AOF文件 ● 每执行一次写命令，立即记录到AOF文件 ● 写命令执行完先放入AOF缓冲区，然后每隔1秒将缓冲区数据写到AOF文件（默认方案） ● 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
        • AOF日志文件重写 为什么要进行重写AOF日志？ 因为是记录命令，AOF文件会比RDB文件大的多。因为AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。所以可以通过执行bgrewriteaof命令，让AOF文件执行重写功能。 具体流程如下： 首先redis会fork一个子进程，重新写一个新的AOF文件，该次重写不是读取旧的AOF文件，而是读取内存中的Redis数据库，重写一份AOF文件，有点类似于RDB的快照方式 ，把RDB的快照，以二进制的形式附在新的AOF头部，作为已有的历史数据，替换掉原来的流水账操作 在执行BGREWRITEAOF 命令（这个就是让AOF重写的指令）时，Redis 服务器会维护⼀个 AOF 重写缓冲区，该缓冲区会在子进程创建新 AOF 文件期间，记录服务器执行的所有写命令。当子进程完成新 AOF 文件之后，服务器会将重写缓冲区中的所有内容追加到新 AOF文件的末尾，使得新的 AOF 文件保存的数据库状态与现有的数据库状态⼀致。最后，服务器用新的 AOF 文件替换旧的AOF文件，以此来完成 AOF 文件重写操作。
    • RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。