当前位置: 首页> 文旅> 旅游 > 西安百度快照优化_龙岩上杭_南阳seo_在线网页制作工具

西安百度快照优化_龙岩上杭_南阳seo_在线网页制作工具

时间:2025/7/11 14:33:21来源:https://blog.csdn.net/aquriushu/article/details/142881813 浏览次数:0次
西安百度快照优化_龙岩上杭_南阳seo_在线网页制作工具

1,持久化

        Redis的持久化是必须的,当Redis服务宕机后,如果没有持久化,重启服务后redis中的数据都将丢失,所有的数据操作都将直连数据库,系统性能会大幅降低,所以在使用Redis做缓存服务时必须持久化Redis数据。Redis持久化有三种方式:RDB(默认,不推荐)、AOF(可用但不推荐)、混合持久化方式(推荐)。

        1.1,RDB(snapshot-快照模式)

        RDB的快照模式是指:达到redis服务设定的某个条件(如60s内有1000次数据增/删/该操作)或redis服务器内存使用率达到指定阈值时,将当前内存中所有redis数据写入名为dump.rdb的文件中,做为当前时刻数据快照。

        1.1.1,开启方式

        redis的RDB持久化方式不需要显试开启,默认就使用该持久化方式,如果想关闭RDB持久化方式,只需注释所有的save触发条件(见1.1.2的触发条件)即可。

        1.1.2,触发条件和文件存储位置

        触发条件的配置如下,达到任意一个即触发生成dump.rdb。可添加自定义条件。

save 900 1              // 900秒内至少有 1 次数据变化

save 300 10            // 300秒内至少有 10 次数据变化

save 60 10000        // 60秒内至少 10000 次数据变化

dbfilename dump.rdb      // 持久化文件名,可手动修改

dir /var/lib/redis               // 持久化数据文件存放位置,可修改

         1.1.3,生成快照方式及原理

        同步:等同于调用【save】命令。使用redis数据操作(存取)线程将当前时刻内存数据写入dump.rdb文件中,会阻塞数据操作;

        异步:等同于调用【bgsave】命令。创建一个子进程,将当前时刻内存数据写入dump.rdb文件,不影响父进程执行数据存取。如果已经有一个后台保存正在运行,或者有另一个非后台保存进程正在运行,特别是正在进行的 AOF 重写,则会返回错误。

        注意:在子进程生成快照的同时,父进程有增删改的操作数据,将会采用写时复制机制(Copy-On-Write, COW)保证这段时间的数据同步至RDB文件。原理是bgsave期间父进程的数据修改,将会被复制一份数据副本,bgsvae在写完rdb后再同步数据副本。

        1.1.4,RDB模式问题

        RDB的生成必须满足触发阈值,生产中不可能设置过于频繁的触发阈值,因为每次生成的RDB都是触发时刻内存中的所有数据。所以当未达到触发阈值时,如果redis服务宕机,则这段时间内的所有操作数据都将丢失。

1.2,AOF(append-only file)

        AOF是优于RDB的持久化方式,将redis数据变化的每一条指令记录到文件appendonly.aof中。实际并非直接写入aof文件,先写入服务器缓存,每隔一段时间调用fsync()将数据同步到磁盘文件。

        1.2.1,开启方式

        redis.conf中有AOF的开启参数,默认为no,开启直接改为yes即可。如果AOF和RDB同时打开,则两种文件(RDB、AOF)都会存在。

appendonly yes             

appendfilename "appendonly.aof"        // 生成的文件名,可手动修改名称

        1.2.2,触发条件 

        同RDB方式一样,AOF也有自己的触发条件

appendfsync no                   // 不主动发起同步,由操作系统决定何时同步。快,但不安全

appendfsync always            // 每个修改数据的命令都同步至AOF文件中。慢,但安全

appendfsync everysec        // 默认。每秒发起一次同步。若同步前redis宕机则丢失1秒数据

        1.2.3,AOF文件解析 

        RDB文件是数据二进制文件,打开时内容如同乱码,如图:

        AOF是将修改数据指令存入文件,如图:

 

        1.2.4,AOF优化策略:AOF重写

        通过上面的文件解析可知,AOF恢复数据的方式是依次执行AOF文件中的命令。但实际情况下,AOF中有很多冗余的命令,如下方场景:

        为某篇文章累加阅读量。假如阅读量累加到5时,redis宕机,此时恢复数据不需依次累加,实则只需执行 set readcount-article1 5即可。基于类似数据场景,AOF提供了内置的优化机制:

AOF重写:达到重写的触发条件后,redis将根据当前内存数据,重新生成AOF文件。

触发条件配置:

auto-aof-rewrite-percentage 100          // aof文件自上次重写后,文件大小增长100%则触发再次重写

auto-aof-rewrite-min-size 64mb           // aof文件达到64M时重写

        使用命令【BGREWRITEAOF】手动触发一次重写,查看上述累加重写前后文件内容:

         注意:重写时,AOF模式采用类似RDB的【bgsave】方式,新建一个子进程重写AOF文件,故重写是不会影响主进程的redis数据操作。

        1.2.4,AOF模式问题

        如果redis运行时间很长,AOF文件将会巨大无比,即便使用了AOF重写,恢复数据时仍旧可能会非常缓慢。

        1.3,混合持久化方式

        RDB持久化方式,数据文件小(二进制数据),恢复数据快,缺点是容易丢失数据。AOF持久化方式,虽然安全但数据文件较大,恢复数据慢。混合持久化整合了两种方式的优点,混合持久化的AOF数据文件由两部分组成:[RDB file] 和 [AOF tail]。

        具体原理:当数据量未达到AOF重写阈值时,数据已redis命令方式写入AOF文件,当触发AOF重写时,当前时刻的数据将以RDB数据格式写入新的aof文件(RDB file),重写过程中的redis数据操作仍旧已命令方式追加写入该文件(AOF tail)。当重写完成后,新AOF文件替换旧的AOF文件。混合持久化文件内容如下:

         1.3.1,开启方式

        redis.conf中有混合持久化的开启参数,默认为no,开启混合持久化方式,需先开启AOF方式,再将下述参数改为yes即可。

aof-use-rdb-preamble yes        

        开启后,重写AOF,重写前的AOF参考1.2.3,重写后AOF如下,

        1.3.2,触发条件

        使用AOF方式的触发机制。tip:当使用混合持久化方式时,可关闭RDB持久化方式。

2,数据恢复

        恢复redis数据非常容易,只需将对应的数据文件放入redis.conf中配置的数据文件目录里即可。如上述案例中,数据文件的存储位置为:

        只需将待恢复数据的文件:dump.rdb或appendonly.aof文件放入该目录,重启reids时会自动恢复文件中数据。

         注意:虽然本章实现了数据的持久化,但当Redis宕机,如果数据操作量巨大,相当于出现【缓存穿透】现象,将极大降低系统性能。故生产中使用Redis一般都会使用主从架构,将在下章讲解。

关键字:西安百度快照优化_龙岩上杭_南阳seo_在线网页制作工具

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com

责任编辑: