怎么用polylang做网站菜单,全屏式网站,周口建设局网站,搭建一个视频网站这里写目录标题一、持久化简介1.1 持久化1.2 Redis持久化的两种形式二、RDB2.1 RDB概念2.2 save指令手动执行一次保存配置相关参数2.3 bgsave指令2.4 save配置自动执行2.5 RDB三种启动方式对比三、AOF3.1 AOF概念3.2 AOF执行策略3.3 AOF重写四、RDB和AOF区别2.1 RDB与AOF对比优缺点2.1 RDB与AOF应用场景一、持久化简介
1.1 持久化 利用存储介质将数据进行保存在特定的时间将保存的数据进行恢复的工作机制称为持久化 。 持久化用于防止数据的意外丢失确保数据安全性。 把数据加载到内存的过程叫做数据恢复。 redis是一个内存数据库一旦断电或服务器进程退出内存数据库中的数据将全部丢失所以需要redis持久化
1.2 Redis持久化的两种形式 第一种将当前数据状态进行保存快照形式存储数据结果存储格式简单关注点在数据。 第二种将数据的操作过程进行保存日志形式存储操作过程存储格式复杂关注点在数据的操作过程。
二、RDB
2.1 RDB概念
RDB简而言之就是在不同的时间点将redis存储的数据生成快照并存储到磁盘等介质上。
2.2 save指令
手动执行一次保存
save配置相关参数
置本地数据库文件名默认值为 dump.rdb通常设置为dump-端口号.rdb
dbfilename filename设置存储.rdb文件的路径通常设置成存储空间较大的目录中注意目录名称必须要存在
dir path设置存储至本地数据库时是否压缩数据默认yes设置为no节省 CPU 运行时间但存储文件变大
rdbcompression yes|no设置读写文件过程是否进行RDB格式校验默认yes设置为no节约读写10%时间消耗单存在数据损坏的风险
rdbchecksum yes|nosave指令工作原理 现在有四个客户端各自要执行一个指令把这些指令发送到redis服务器后他们执行有一个先后顺序问题redis是个单线程的工作模式它会创建一个任务队列所有的命令都会进到这个队列里边在这儿排队执行执行完一个消失一个当所有的命令都执行完了OK结果达到了。 但是如果现在我们执行的时候save指令保存的数据量很大会是什么现象呢 他会非常耗时以至于影响到它在执行的时候后面的指令都要等所以说这种模式是不友好的这是save指令对应的一个问题当cpu执行的时候会阻塞redis服务器直到他执行完毕所以说我们不建议大家在线上环境用save指令。
2.3 bgsave指令
save单线程执行方式造成效率过低bgsave指令bg其实是background的意思后台执行。
手动启动后台保存操作但不是立即执行
bgsavebgsave指令相关配置
后台存储过程中如果出现错误现象是否停止保存操作默认yes
stop-writes-on-bgsave-error yes|no其 他
dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|nobgsave指令工作原理 当执行bgsave的时候客户端发出bgsave指令给到redis服务器。注意这个时候服务器马上回一个结果告诉客户端后台已经开始了与此同时它会创建一个子进程使用Linux的fork函数创建一个子进程让这个子进程去执行save相关的操作此时我们可以想一下我们主进程一直在处理指令而子进程在执行后台的保存它会不会干扰到主进程的执行吗
答案是不会所以说他才是主流方案。子进程开始执行之后它就会创建啊RDB文件把它存起来操作完以后他会把这个结果返回也就是说bgsave的过程分成两个过程第一个是服务端拿到指令直接告诉客户端开始执行了另外一个过程是一个子进程在完成后台的保存操作操作完以后回一个消息。
2.4 save配置自动执行
设置自动持久化的条件满足限定时间范围内key的变化数量达到指定数量即进行持久化
save second changes参数
second监控时间范围
changes监控key的变化量
范例
save 900 1
save 300 10
save 60 10000其他相关配置
dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no
stop-writes-on-bgsave-error yes|no2.5 RDB三种启动方式对比
方式save指令bgsave指令读写同步异步阻塞客户端指令是否额外内存消耗否是启动新进程否是
RDB特殊启动形式
服务器运行过程中重启
debug reload关闭服务器时指定保存数据
shutdown saveRDB优点
RDB是一个紧凑压缩的二进制文件存储效率较高RDB内部存储的是redis在某个时间点的数据快照非常适合用于数据备份全量复制等场景RDB恢复数据的速度要比AOF快很多应用服务器中每X小时执行bgsave备份并将RDB文件拷贝到远程机器中用于灾难恢复。
RDB缺点
RDB方式无论是执行指令还是利用配置无法做到实时持久化具有较大的可能性丢失数据bgsave指令每次运行要执行fork操作创建子进程要牺牲掉一些性能Redis的众多版本中未进行RDB文件格式的版本统一有可能出现各版本服务之间数据格式无法兼容现象
三、AOF
3.1 AOF概念
AOF(append only file)持久化以独立日志的方式记录每次写命令重启时再重新执行AOF文件中命令 达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
AOF的主要作用是解决了数据持久化的实时性目前已经是Redis持久化的主流方式 启动AOF相关配置
开启AOF持久化功能默认no即不开启状态
appendonly yes|noAOF持久化文件名默认文件名为appendonly.aof建议配置为appendonly-端口号.aof
appendfilename filenameAOF持久化文件保存路径与RDB持久化文件保持一致即可
dirAOF写数据策略默认为everysec
appendfsync always|everysec|no3.2 AOF执行策略
AOF写数据三种策略(appendfsync) always(每次每次写入操作均同步到AOF文件中数据零误差性能较低不建议使用。 everysec每秒每秒将缓冲区中的指令同步到AOF文件中在系统突然宕机的情况下丢失1秒内的数据 数据准确性较高性能较高建议使用也是默认配置 no系统控制由操作系统控制每次同步到AOF文件的周期整体过程不可控
3.3 AOF重写
什么叫AOF重写
随着命令不断写入AOF文件会越来越大为了解决这个问题Redis引入了AOF重写机制压缩文件体积。AOF文件重 写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结 果转化成最终结果数据对应的指令进行记录。
AOF重写作用
降低磁盘占用量提高磁盘利用率提高持久化效率降低持久化写时间提高IO性能降低数据恢复用时提高数据恢复效率
AOF重写方式
手动重写
bgrewriteaof自动重写
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage四、RDB和AOF区别
2.1 RDB与AOF对比优缺点
OF对比优缺点
持久化方式RDBAOF占用存储空间小数据级压缩大指令级重写存储速度慢快恢复速度快慢数据安全性会丢失数据依据策略决定资源消耗高/重量级低/轻量级启动优先级低高
2.1 RDB与AOF应用场景
RDB与AOF的选择之惑
对数据非常敏感建议使用默认的AOF持久化方案
AOF持久化策略使用everysecond每秒钟fsync一次。该策略redis仍可以保持很好的处理性能当出 现问题时最多丢失0-1秒内的数据。
注意由于AOF文件存储体积较大且恢复速度较慢
数据呈现阶段有效性建议使用RDB持久化方案
数据可以良好的做到阶段内无丢失该阶段是开发者或运维人员手工维护的且恢复速度较快阶段 点数据恢复通常采用RDB方案
注意利用RDB实现紧凑的数据持久化会使Redis降的很低慎重总结
综合比对
RDB与AOF的选择实际上是在做一种权衡每种都有利有弊如不能承受数分钟以内的数据丢失对业务数据非常敏感选用AOF如能承受数分钟以内的数据丢失且追求大数据集的恢复速度选用RDB灾难恢复选用RDB双保险策略同时开启 RDB和 AOF重启后Redis优先使用 AOF 来恢复数据降低丢失数据的量
