后端学习

#后端学习| 来源: 网络整理| 查看: 265

一、简介

Redis的持久化用于应对系统灾难性数据丢失例如停电，Redis将内存中存储的数据存在硬盘中用于数据恢复。Redis有两种保存方式：

RDB，采用数据快照的形式将数据的二进制数据直接存入硬盘，存储格式简单，关注点数据。AOF，将Redis的操作日志存入硬盘中，存储格式复杂，关注点数据的操作过程。二、RDB1.配置信息# 设置本地数据库文件名，默认值dump.rdb。 # 推荐：dump-端口号.rdb dbfilename dump.rdb # 设置存储文件存储路径，默认./，启动服务路径下。 # 推荐：大存储空间中，目录名data dir ./ # 设置存储到本地数据库时是否压缩数据，默认yes，采用LZF压缩。 # 若设置为no，可以节省CPU运行时间，但存储数据会变大 rdbcompression yes # 设置是否进行RDB文件格式校验，读写文件都会进行，默认yes。 # 设置为no，可以节约读写过程时间消耗，但是存储数据可能损坏 rdbchecksum yes # 后台存储过程中如果出现错误现象，是否停止保存。默认开启。 stop-writes-on-bgsave-error yes2.save指令# 通过命令save启动，每手动执行一次就会存储一次数据，例如： set name 123 save #数据会在redis服务启动时自动读取dump文件恢复

注意：redis是单线程执行任务，执行save时会阻塞整个Redis服务器，直到RDB过程结束，有可能会造成长时间阻塞，线上环境不建议使用。

3.bgsave指令# 后台执行save，直接执行bgsave即可： bgsave

执行原理：用户发送bgsave指令给Redis服务，Redis服务器会返回Background saving started表示后台保存数据已经开始。同时Redis服务器会调用fork函数生成子进程不阻塞Redis服务，单独使用子进程执行RDB过程，结束后子进程返回消息告诉Redis服务器RDB过程执行结束。

bgsave执行过程

bgsave命令是针对save阻塞问题做的优化。Redis内部涉及需要进行RDB操作的都使用basave指令。

4.save配置# 写在conf配置文件里，save可以配置多条 # 满足指定时间范围内，key的变化数量达到指定数量到达指定时间后进行持久化 # second 监控时间范围，changes 监控key的变化量 # save second changes，默认配置如下 save 3600 1 save 300 100 save 60 10000 # 说明 # 第60秒之后，超过10000次修改，立即进行持久化 # 第300秒之后，超过100次修改，立即执行持久化 # 第3600秒之后，超过1次修改，立即执行持久化 # 自动执行持久化使用的bgsave指令5.save&bgsavesave：同步读写，会阻塞服务，但不会启动新进程，不会额外消耗内存。bgsave：异步读写，不会阻塞服务，但会启动新进程，会额外消耗内存。6.其他启动RDB的形式全量复制时启动。服务器运行过程中重启，reload。该方案谨慎使用可能会导致数据丢失。关闭服务器时指定保存数据，shutdown save。7.RDB优缺点

优点：

RDB是一个紧凑压缩的二进制文件，存储效率高。RDB内部存储是以某个时间点的数据快照，非常适合用于数据备份，全量复制等场景。RDB恢复数据的速度要比AOF快很多。

缺点：

RDB方式无法做到实时持久化，具有较大的可能性丢失数据。bgsave指令要执行fork函数创建子进程，要牺牲一部分性能。Redis的众多版本的RDB文件格式不一致，有可能出现不同版本不兼容的情况。三、AOF1.配置信息# 是否开启AOF功能，默认不开启 appendonly no # AOF写数据策略，always|everysec|no appendfsync everysec # always：每次写入操作均同步到AOF文件，数据零误差，性能低。 # everysec：每秒将缓冲区中的指令同步到AOF文件，数据准确性高，性能高。推荐使用，默认设置。 # no：系统控制，由系统控制每次同步到AOF文件的周期，整体不可控。 # AOF文件名，推荐appendonly-端口号.aof。存储路径和rdb路径一致 appendfilename filename2.AOF执行原理

用户每次写操作传入redis服务后，redis服务将写操作记录到AOF写命令的缓冲区，然后在写到aof文件中，什么时候将数据从缓冲区写入aof文件由AOF写数据策略控制。

3.AOF重写

随着指令越来越多AOF文件也会越来越大，由此Redis引入了AOF重写机制，通过一定的规则将无用的指令清除。

AOF重写机制的好处：

降低磁盘占用量，提高磁盘利用率提高持久化效率，降低持久化写时间，提高IO性能降低恢复数据用时，提高数据恢复效率4.AOF重写规则进程内超时数据不在写入忽略无效指令，只爆率最终结果指令，如set key1 1，del key1；set key2 2，set key2 等。对同一条数据的多条写命令合并为一条，如lpush list1 a，lpush list 2，合并为lpush list1 a b。5.AOF重写方式# 手动执行指令。后台重写aof文件，工作流程和bgsave基本一致。 bgrewriteaof # 自动重写，配置信息 # auto-aof-rewrite-min-size：最小重写尺寸 # auto-aof-rewrite-percentage：增量达到多少重写 auto-aof-rewrite-min-size size auto-aof-rewrite-percentage percent # 自动重写触发的对比参数，可以运行info Persistence获取具体信息 # aof_current_size：aof当前尺寸 # aof_base_size: aof基础尺寸 # 自动重写触发条件 # 当aof_current_size > auto-aof-rewrite-min-size触发重写 # 当(aof_current_size-aof_base_size)/aof_base_size > auto-aof-rewrite-percentage触发重写6.AOF重写流程

执行aof重写指令，redis将新开辟一个aof重写缓存区，写指令将继续正常写入aof缓冲区并和aof重写缓冲区。AOF重写执行会拿去重写开始时的数据快照将其转换为写操作，然后将aof重写缓冲区的数据追加进入重写AOF文件，最后所有工作完毕将重写aof文件替换掉非重写aof文件并回到正常的AOF流程。

AOF文件重写流程四、RDB & AOF1.对比RDB：存储空间小，储出速度慢，数据恢复快，会导致部分数据丢失，资源消耗高，启动优先级低。AOF：存储空间大，存储速度快，恢复速度慢，数据安全性高，资源消耗低，启动优先级高。2.选择

对数据敏感不能容忍数据的大量丢失使用AOF，对数据不敏感追求数据的快速恢复使用RDB。也可以两种综合使用，但注意综合使用操作不当会导致数据的大规模丢失。AOF高优恢复，但是在AOF恢复，RDB还未开始恢复触发RDB过程会导致RDB被覆盖数据丢失。

附录其他学校内容

后端学习内容

【本文地址】

后端学习

后端学习

今日新闻

推荐新闻