redis的持久化怎么理解

这篇文章主要讲解了“redis的持久化怎么理解”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“redis的持久化怎么理解”吧！

redis的持久化：

    概念：将内存中的数据保存到磁盘，在机器宕机或重启时可以保证数据不丢失。
    
    说明：建议RDB和AOF同时开启，若二者同时开启，则redis在启动时优先使用aof文件来恢复数据，若读取aof文件失败，则读取rdb文件来恢复数据。

    RDB(Redis DataBase)
        概念：
            将内存中的数据进行快照并且存储到磁盘上，即在指定目录下生成一个dump.rdb文件。RDB是redis默认的持久化方式。
            redis启动后可用通过读取rdb文件，将数据再次载入到内存中，一般情况下1G的rdb文件载入到内存的时间大概为20~30秒。
            
        过程：把所有的数据都写到一个临时文件中，然后用这个临时文件替换掉之前的rdb文件。
        
        触发机制：
            手动触发：
                save命令：阻塞Redis当前的进程，直到RDB过程完成为止。若实例占用的内存比较大，则会造成redis服务长时间的不可用。(不建议使用)
                bgsave命令：redis当前进程执行fork操作创建子进程，RDB持久化过程由子进程负责，父进程继续接收并处理客户端发出的请求。阻塞只发生在fork阶段，一般时间很短。
                    注意：fork一个进程时，子进程占用的内存空间与父进程相同。
            自动触发：
                达到配置的条件时，自动触发bgsave命令。
                在执行shutdown命令后会自动触发bgsave命令。
        
            配置文件redis.conf：

                # 设置触发快照的条件(Will save the DB if both the given number of seconds and the given number of write operations against the DB occurred.)
                # 格式：save <seconds> <changes>
                save 900 1         # 900秒内，如果有1个以上(包括1个)的key被修改了，则触发快照。
                save 300 10        # 300秒内，如果有10个以上(包括10个)的key被修改了，则触发快照。
                save 60 10000    # 60秒内，如果有10000个以上(包括10000个)的key被修改了，则触发快照。
                
                # RDB默认会开启，关闭RDB方式的持久化
                save ""
                
                # 设置rdb文件的名称
                dbfilename dump.rdb

                # 设置redis的工作目录，即rdb文件、aof文件所在的目录
                # The working directory.
                # The DB will be written inside this directory, with the filename specified above using the 'dbfilename' configuration directive.
                # The Append Only File will also be created inside this directory.
                dir ./
                
                # 设置rdb文件是否进行压缩，默认为yes。注：压缩rdb文件可以减少磁盘空间的占用，但是需要消耗额外的cpu。
                rdbcompression yes
    
        优点：适合大规模的数据恢复，且数据加载的速度比较快。
        缺点：无法做到数据实时的(秒级)持久化。故数据备份的完整性不高。

    AOF(Append Only File)
        概念：
            将发送到redis服务端的每一条写操作都存储到磁盘上，即在指定目录下生成一个appendonly.aof文件，并且将每次的写操作追加到aof文件的末尾。
            redis启动后通过读取aof文件，将aof文件中的写操作依次再执行一遍，以此来达到数据恢复的效果。
        
        过程：命令写入(append)到缓存区、将缓存区的数据同步到aof文件中(sync)、重新aof文件(rewrite)
            重写aof文件：
                目的：去除数据的中间执行过程，保留最终数据的命令，可大大减小aof文件的大小，从而可以加快数据恢复的速度。
                过程：redis当前进程执行fork操作创建子进程(开销等同于bgsave过程)，子进程根据命令合并规则将内存中的数据写入到新的AOF文件中，最后用新的aof文件替换掉现有的aof文件。
        
        触发机制：
            手动触发：
                BGREWRITEAOF
                若aof文件格式异常，则需要修复aof文件：redis-check-aof --fix appendonly.aof
            自动触发：
                达到配置的条件时，自动触发更新aof文件 或 重新aof文件 的操作。
        
        3)配置文件redis.conf：

            # AOF和RDB可以同时存在，AOF方式的持久化拥有更好的数据完整性和一致性。
            # AOF and RDB persistence can be enabled at the same time without problems. 
            # If the AOF is enabled on startup Redis will load the AOF, that is the file with the better durability guarantees.
    
            # 开启AOF (AOF默认是关闭的appendonly no)
            appendonly yes
            
            # 设置触发更新aof文件的条件
            # appendfsync always    # 同步持久化，即每次执行写操作后都会去更新aof文件。数据完整性好，但是性能较差。
            appendfsync everysec    # 每秒同步一次，是AOP默认触发更新日志的条件。
            # appendfsync no        # 不主动同步，由操作系统来决定什么时候同步(一般为30s)，性能最好但是持久化得不到保障，故不推荐使用该配置。
            
            # 设置触发重写aof文件的条件，多个条件是"与"的关系。
            # redis在重写aof文件后会将aof文件的大小记录下来(若没有重写过aof文件，则这个大小默认是redis启动时aof文件的大小)
            auto-aof-rewrite-percentage 100        # 当前aof文件的大小 超过 上一次重写后记录的大小 的 100%。
            auto-aof-rewrite-min-size 64mb        # 当前aof文件大于等于64mb。注一般不会设置的这么小，看情况设为ngb比较合理。
            
            # 设置aof文件的名称
            # appendfilename appendonly.aof

            # 设置redis的工作目录，即rdb文件、aof文件所在的目录
            dir ./
            
        优点：可以做到数据实时的(秒级)持久化，故数据备份的完整性很高。
        缺点：AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢，故redis在AOF中引入了重写aof文件的机制。

    持久化给redis带来的开销：
        概念：子进程在重写RDB文件和重写AOF文件时会消耗cpu、内存、硬盘等资源。
        
            cpu：子进程负责把进程内的数据分批写入文件，这个过程属于CPU密集操作，通常子进程对单核CPU利用率接近90%。
            
            内存：父进程fork子进程时，子进程默认占用的内存同父进程一样。我们可以修改Linux内存分配的配置，避免物理内存不足导致fork进程失败。
            
            硬盘：往rdb文件或aof文件中写数据的过程中，磁盘io的压力比较大。
                说明：开启AOF的Redis在高流量写入时，如果使用普通机械磁盘，写入吞吐一般在100MB/s左右，这时Redis实例的瓶颈主要在AOF同步硬盘上。

        注意：redis实例不应该和其它对cpu、内存、硬盘敏感的服务混部。

感谢各位的阅读，以上就是“redis的持久化怎么理解”的内容了，经过本文的学习后，相信大家对redis的持久化怎么理解这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！