做a图片视频在线观看网站,wordpress htaccess 文件位置,建筑行业新闻资讯,html代码中标签的书写不区分大小写1#xff0c;持久化 Redis的持久化是必须的#xff0c;当Redis服务宕机后#xff0c;如果没有持久化#xff0c;重启服务后redis中的数据都将丢失#xff0c;所有的数据操作都将直连数据库#xff0c;系统性能会大幅降低#xff0c;所以在使用Redis做缓存服务时必须持久…1持久化 Redis的持久化是必须的当Redis服务宕机后如果没有持久化重启服务后redis中的数据都将丢失所有的数据操作都将直连数据库系统性能会大幅降低所以在使用Redis做缓存服务时必须持久化Redis数据。Redis持久化有三种方式RDB(默认不推荐)、AOF(可用但不推荐)、混合持久化方式(推荐)。 1.1RDBsnapshot-快照模式 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.4RDB模式问题 RDB的生成必须满足触发阈值生产中不可能设置过于频繁的触发阈值因为每次生成的RDB都是触发时刻内存中的所有数据。所以当未达到触发阈值时如果redis服务宕机则这段时间内的所有操作数据都将丢失。
1.2AOFappend-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.3AOF文件解析 RDB文件是数据二进制文件打开时内容如同乱码如图 AOF是将修改数据指令存入文件如图 1.2.4AOF优化策略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.4AOF模式问题 如果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一般都会使用主从架构将在下章讲解。
