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
                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的持久化怎么理解这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!


分享名称:redis的持久化怎么理解
分享链接:http://myzitong.com/article/ihopoh.html