Redis篇之Redis持久化的实现

持久化即把数据保存到可以永久保存的存储设备当中（磁盘）。因为Redis是基于内存存储数据的，一旦redis实例当即数据将会全部丢失，所以需要有某些机制将内存中的数据持久化到磁盘以备发生宕机时能够进行恢复，这一过程就称之为持久化。

Redis中有有以下两种持久化方式

1. AOF持久化
2. RDB持久化

AOF持久化及其相关实现

1、什么是AOF持久化？

AOF持久化是通过保存redis所执行的命令来记录数据状态的。以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来，只允许追加文件不允许改写文件。在redis重启后，会读取该文件用于数据的重新构建。

2、AOF持久化流程

1. 客户端写入命令执行成功后，会被append追加到AOF缓冲区内
2. AOF缓冲区根据AOF持久化策略【always|everysec|no】将操作异步追加至磁盘的AOF文件中
3. AOF文件超过重写策略或手动重写时，会对AOF文件进行rewrite重写，压缩AOF文件容量
4. 当redis服务重启时，会加载AOF文件中的写操作达到恢复数据的目的

3、AOF持久化策略

Redis提供了三种写磁盘的策略：Always、EverySecend、No，分别对应每条指令保存一次、每秒保存一次、不保存

• Always：每次执行一个命令保存一次
  • 在此策略下，成功执行任务之后会同步写入磁盘，写入成功后才会将结果返回给客户端，此时redis主线程是阻塞状态的。
  • 如果在写入过程中redis服务宕机且此时内存数据写入成功，那么在redis重启后，该数据会丢失
  • EverySecend：每秒保存一次
    • 在此策略下，成功执行任务之后会写入AOF缓冲区然后立即返回结果，不需要等待AOF文件写入成功。且由于AOF缓冲区是在内存中开辟的空间，所以写入速度很快。
    • 如果写入过程中redis服务宕机且内存中的数据写入成功，那么在redis重启后，宕机前一秒钟（时间取决于同步之后到宕机的时间差，可能不足一秒钟）的数据会丢失。（一般情况下推荐使用此策略，取性能和安全性的平衡点）
    • No：不保存
      • 在此策略下，成功执行任务之后会写入AOF缓冲区然后立即返回结果，但是AOF缓冲区的数据何时写入磁盘完全由操作系统决定。
      • 如果发生宕机的情况，数据的丢失将取决于操作系统。

        三种策略对比

        4、AOF文件重写

        AOF文件为什么需要重写？

        因为在服务运行过程中，会不停的有数据追加写入AOF文件，那么AOF文件就会不停的变大。如果不进行重写，不仅占用多余的内存，且在redis服务重启后恢复数据的时间也会加长。

        AOF文件重写不是针对于原有的AOF文件进行任何的写入和读取，而是针对当前redis数据库中键的当前值。比如之前有一个键list，对其执行了5条命令，那么在重写时，会直接取当前数据库中该list对应的值进行设置，只需要写入一条命令即可。

        AOF文件的重写过程

        1. 主线程在执行写命令时，如果当前的AOF文件大小触发了重写基准值（AOF当前大小>=）base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下）或者手动执行了bgrewriteaof命令
        2. 主进程fork出子进程执行重写操作，主进程继续处理新的写入命令
        3. 子进程copy当前redis内存中的数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间新的数据修改不会丢失
        4. 子进程写完新的AOF文件后，向主进程发信号，主进程更新统计信息
        5. 主进程把aof_rewrite_buf中的数据写入新的AOF文件
        6. 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写

        为什么redis将AOF文件的重写程序放入子进程？

        • 子进程重写期间，主进程可以继续处理其他的写请求，避免阻塞
        • 主进程带有数据进程的数据副本，使用子进程而不是线程，可以避免使用锁的情况下保证数据的安全性。

          RDB快照及其实现

          1、什么是RDB？

          RBD（Redis DataBase）是Redis的一种数据持久化策略，是一种以内存快照形式保存Redis数据的方式。所谓快照就是指把某一刻的状态以文件的形式进行全量备份到磁盘，这个快照文件就称为RDB文件。

          2、快照怎么用？

          Redis提供了两个命令来生成RDB文件，分别是save、bgsave。

          • save：执行此命令会在主线程生成RDB文件，因此会阻塞主线程处理其他新的请求
          • bgsave：会创建一个子进程来生成RDB文件，可以避免主线程阻塞

            此外，还可以通过redis配置文件来调整RDB文件的生成策略。比如可以设置save 900 1意为在900秒之内至少发生了一次修改，就会进行生成RDB文件

            需要注意，因为RDB文件生成是全量备份，所以设置的生成时间不能过于频繁，否则会对Redis性能产生影响。但是也不能将频率设置的太低，否则在redis宕机时丢失的数据会更多。通常来说，设置至少五分钟保存一次快照。

            3、在生成RDB快照时，是否还能修改数据库中的数据？

            可以。

            在执行bgsave过程中，redis依然可以继续处理操作命令，依靠的就是COW（copy on write）写时复制技术。

            执行bgsave命令时，会通过fork()创建子进程，此时的子进程和父进程是共享同一片内存数据的，子进程的页表是复制的父进程的页表，但是二者的页表指向的物理地址还是同一个。这样可以加快父进程创建子进程的速度，因为在创建子进程时父进程会阻塞。

            4、什么是COW？

            COW（copy on write）写时复制技术，是一种内存管理技术，它允许多个进程共享同一块内存，只有在某个进程尝试修改内存时，才会将内存复制一份，以确保数据一致性。

            在redis生成RDB快照时，由于父子进程共享同一块内存数据，当父进程接收到新的写操作命令时，就会另外复制一份，然后父进程在这个数据副本上进行数据的修改操作。与此同时，子进程则继续把原来的数据写入RDB快照文件。

            需要注意，由于在生成RDB文件时，发生的写操作由父进程在生成的数据副本中进行处理，所以子进程在生成RDB文件时无法记录操作过程中的修改信息，只能保存原有的数据文件。而在操作过程中的修改信息则需要在下一次的RDB文件生成时才会得以备份。

            AOF和RDB总结

            1、二者的简单描述

            AOF：把所有对Redis的服务器进行修改的命令都追加写入一个文件中，该文件是一个命令的集合

            RDB：快照形式直接把内存中的数据以二进制的形式保存到一个dump.rdb文件中，定时保存。

            2、redis的默认持久化方式

            Redis默认情况下，是快照 RDB 的持久化方式，将内存中的数据以快照的方式写入二进制文件中，默认的文件名是 dump.rdb 。当然我们也可以手动执行 save 或者 bgsave（异步）做快照。

            3、二者的优缺点：

            • 优点
              • RDB：适用于大规模的数据备份，并且在设置好快照生成规则后可以精准的将数据恢复到某一个时间点。且由于生成的是全量数据的快照文件，恢复速度也会比AOF更快。
              • AOF：备份机制更加文件，数据丢失少，备份日志文件可读。
              • 缺点
                • RDB：不适用于用于实时数据备份的解决方案，一旦发生意外宕机，丢失数据会比较多。
                • AOF：备份频率高，占用内存大，恢复速度相对慢，性能压力大。

                  4、在实际生产中应该如何选择？

                  • 对数据完整性要求高，不需要考虑redis性能瓶颈：AOF
                  • 对数据完整性要求不高：RDB

                    数据库备份和灾难恢复：定时生成RDB快照更加便于数据库备份，并且RDB恢复数据的速度也要比AOF恢复的速度更快。

                    在redis4.0之后，支持同时开启RDB和AOF，系统重启后，redis会优先使用AOF来恢复数据，降低数据的丢失程度。