Redis6之持久化操作

目录

RDB

触发

工作流程

持久化备份

优点

缺点

AOF

触发

频率配置

持久化流程

数据修复

优点

缺点

混合持久化

触发

 优点

缺点

如何选择

---

 redis是一个内存数据库，一旦断电或服务器进程退出，内存数据库中的数据将全部丢失，所以需要redis持久化;

        redis持久化就是把数据保存在磁盘上，利用永久性存储介质将数据保存，在特定的时间将保存的数据进行恢复的工作机制;

redis提供三种持久化机制：

        RDB:存储数据结果，关注点在数据

        AOF:存储操作过程，关注点在数据的操作过程

        混合持久化：Redis4.0中新增方式，集成了rdb和aof中的优点

RDB

        在指定的时间间隔内（定时）将内存中的数据集写入磁盘，也就是快照,数据恢复是将快照文件直接读到内存中

触发

        1、save命令：执行一个同步操作，以rdb文件的方式保存所有的数据快照

        save命令会占用内存 数据集较小时没有影响 但是如果数据集较大 或者消费者较多时 很容易发生redis阻塞 因为save是一个同步时操作 会影响后面的进程

        2、bgsave命令：执行一个异步操作，以RDB文件的方式保存所有数据的快照

        后台存储，在执行bgsave时 Redis会使用Linux系统中的 fokc() 去生成一个子线程来处理数据的快照 

        3、redis.conf配置文件设置        

             如：save 900 1 // 900 秒内，对数据库至少修改 1 次

工作流程

        1、Redis调用forks()，同时拥有父进程和子进程

        2、子进程将数据写入临时的rdb文件中

        3、当子进程完成对rdb的文件写入时，Redis会用新的rdb文件替换旧的rdb文件，并删除旧的rdb文件

持久化备份

        应该要定时定期的通过脚本对Redis持久化文件进行转移备份，这样双重保险，更加可靠，万一遇到突发情况，也是多一手解决方案，防止出现网络分区或者部分节点宕机甚至是硬件损坏的情况发生

优点

        1、RDB是一个紧凑压缩的二进制文件，存储紧凑，节省内存空间

        2、恢复速度快

        3、适合全量备份、全量复制的场景，经常用于灾难恢复

缺点

        1、RDB方式数据没办法做到实时持久化/秒级持久化

        2、RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题

AOF

        以日志的形式记录写操作(增删改操作)，将Redis执行的所有写指令都记录下来到缓冲区(读操作不记录)，然后追加到AOF文件中，当redis重新启动时，就会去重新执行一遍日志文件中的命令来恢复数据；

触发

        修改aof的配置文件：appendonly.aof

        AOF默认不开启，默认为appendonly no，开启则需要修改为appendonly yes

频率配置

        AOF日志是以文件的形式存在的，当程序对AOF日志文件进行写操作时，实际上将内容写到了内核为文件描述符分配的一个内存缓冲区中，随后内核会异步的将缓冲区中的数据刷新到磁盘中。如果缓冲区中的数据没来得及刷回磁盘时，服务器宕机了，这些数据就会丢失

        1、appendfsync always:每次Redis写操作，都写入AOF日志

        2、appendfsync everysec:每秒刷新一次缓冲区中的数据到AOF文件，这个Redis配置文件中默认的策略，兼容了性能和数据完整性的折中方案，这种配置，理论上丢失的数据在一秒钟左右

        3、appendfsync no:不会主动的去刷新缓冲区中的数据到AOF文件中，而是直接交给操作系统去判断，这种操作也是不推荐的，丢失数据的可能性非常大

持久化流程

        1、客户端的写操作请求被追加到AOF缓冲区

        2、AOF根据持久化策略将操作sync同步到磁盘的AOF文件中

        3、AOF文件大小超过重写策略或者手动重写时，会对AOF文件进行rewrite重写，压缩AOF文件容量

        4、redis重启时，会去读取AOF的写操作进行数据恢复

数据修复

        AOF持久化机制正常恢复与RDB持久化机制的恢复是一样的，都只需要将备份文件放置到Redis的工作目录下，Redis启动时就会自动的加载。AOF持久化机制提供了AOF文件异常时恢复的功能，这个功能在AOF文件损坏的场景中经常被使用到

优点

        1、数据备份更加完整，丢失数据的概率更低

        2、日志文件可读，操作性更强，可以通过操作日志文件来进行修复

缺点

        1、AOF文件比RDB更占空间

        2、因为要执行记录的写操作，恢复起来更慢

混合持久化

        集合两者的优点，Redis 4.0提出了混合使用RDB和AOF来做持久化，既保证了Redis重启速度，又降低数据丢失风险；

        混合持久化工作在AOF日志重写过程，当开启了混合持久化时，在AOF重写日志时，fork出来的重写子进程会先将与主线程共享的内存数据以RDB方式写入到AOF文件，然后主线程处理的操作命令会被记录在重写缓冲区里，重写缓冲区里的增量命令会以AOF方式写入到AOF文件，写入完成后通知主进程将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。

        使用了混合持久化，AOF文件的前半部分是RDB格式的全量数据，后半部分是AOF格式的增量数据。其日志文件结构如下：

触发

        混合持久化通过配置：aof-use-rdb-preamble yes开启，Redis 4.0以上版本默认开启

 优点

        混合持久化结合了RDB和AOF持久化的优点，开头为RDB的格式，使得Redis可以更快的启动，同时结合AOF的优点，有减低了大量数据丢失的风险

缺点

  AOF文件中添加了RDB格式的内容，使得AOF文件的可读性变得很差

     兼容性差，如果开启混合持久化，那么此混合持久化AOF文件，就不能用在Redis 4.0之前版本了

如何选择

        1、需要很高的性能，或者宕机之后能够尽快的恢复，而对数据完整性的要求不是那么高，那么可以采用RDB持久化的方式

        2、对数据完整性的要求很高，那么可以采用AOF的持久化方式，而至于采用那种回写策略，则取决于你对数据完整性的要求程度

        3、既要兼顾性能，又注重数据完整性，那么可以采用混合持久化的方式

        4、对数据丢失无所谓，追求性能最大化的情况下，你也可以不使用任何持久化方式