淘宝网站建设方案,如何进行网站的推广,支付单页网站模板,网站群的建设策略目录 策略RDBbgsave执行流程RDB效果演示RDB优缺点 AOFAOF缓冲区刷新策略AOF的重写机制AOF重写机制的触发机制AOF重写流程 混合持久化同时存在aof和rdb快照#xff0c;以谁为主#xff1f;信号 策略
RDB Redis DataBase 相当于定期的方式实现持久化AOF Append Only… 目录 策略RDBbgsave执行流程RDB效果演示RDB优缺点 AOFAOF缓冲区刷新策略AOF的重写机制AOF重写机制的触发机制AOF重写流程 混合持久化同时存在aof和rdb快照以谁为主信号 策略
RDB Redis DataBase 相当于定期的方式实现持久化AOF Append Only File 相当于实时的方式实现持久化
RDB RDB定期的把我们Redis内存中的所有数据都写入硬盘中生成一个“快照” Redis给内存中当前存储的这些数据赶紧拍个照片生成一个文件存储在硬盘中~~ 后续Redis一旦重启了就可以根据刚才的“快照”就能把内存中的数据给恢复回来~ “定期”具体来说又有两种方式 1.手动触发. 程序员通过redis客户端执行特定的命令来触发快照生成 save bgsave 2.自动触发. 在Redis配置文件中设置一下让Redis每隔多长时间/每产生多少次修改就触发。 save执行save的时候redis就会全力以赴的进行“快照生成”操作此时就会阻塞redis的其他客户端的命令~导致类似于keys*的效果 一般不建议使用save bgsavebgbackground 不会影响Redis服务器处理其他客户端的请求和命令 Redis咋做到的是不是搞了个多线程啥的 并非如此 并发编程的场景.此处redis使用的是“多进程”的方式来完成的并发编程来完成的bgsave的实现。 bgsave执行流程 1.判断当前是否存在其他正在工作的子进程。 比如现在已经有一个子进程正在执行bgsave此时就直接把当前的bgsave返回~ 2.如果没有其他的工作子进程就通过fork这样的系统调用创建一个子进程来~ fork是linux系统提供的一个创建子进程的api(系统调用) fork创建子进程简单粗暴直接把当前的进程(父进程)复制一份作为子进程~ 一旦复制完成了父子进程就是两个独立的进程就各自执行各自的了~~ 3.子进程负责进行写文件生成快照的过程. 父进程继续接收客户端的请求继续正常提供服务. 4.子进程完成整体的持久化过程之后就会通知父进程干完了父进程就会更新一些统计信息子进程就可以结束销毁了。
RDB效果演示 rdb文件中的数据不是你这边插入了数据就会立即更新的 1.手动执行savebgsave触发一次快照 由于我们的数据比较少执行bgsave瞬间就完成了立即查看应该就是有结果的.如果以后我们接触的数据多了执行bgsave就可能需要消耗一定的时间立即查看不一定就是生成完毕了~
通过上述操作就可以看到redis服务器在重新启动的时候加载了rdb文件的内容恢复了内存中之前的状态。 2.插入新的key不手动执行bgsave 发现没有重新启动redis服务器 发现就有了redis生成快照操作不仅仅是手动执行命令才触发也可以自动触发 1)通过刚才配置文件中save执行M时间内修改N次 2)通过shutdown命令(redis里的一个命令)关闭redis服务器也会触发。 3)redis进行主从复制的时候主节点也会自动生成rdb快照然后把rdb快照文件内容传输给从节点
如果是通过正常流程重新启动redis服务器此时redis服务器会在退出的时候自动触发生成rdb操作但是如果是异常重启(kill -9 或者 服务器掉电)此时redis服务器来不及生成rdb内存尚未保存到快照中的数据就会随着重启而丢失~
3.bgsave操作流程是创建子进程子进程完成持久化操作. 持久化会把数据写入新的文件中然后使用新的文件替换旧的文件. liunx文件系统. 文件系统典型的组织方式(ext4)主要是把整个文件系统分成了三个大的部分 1.超级块(放的是一些管理信息) 2.inode区(存放inode节点每个文件都会分配一个inode数据结构包含了文件的各种元数据) 3.block区存放文件的数据内容了。 4.通过配置自动生成rdb快照 执行FLUSHALL也会清空rdb文件 5.如果把rdb文件故意改坏了会咋样 手动的把rdb文件内容改坏. 然后一定是通过kill进程的方式重新启动redis服务器. 如果通过service redis-server restart重启就会在redis服务器退出的时候重新生成rdb快照。 就把咱门刚才改坏了的文件给替换了~~ RDB优缺点
RDB是一个紧凑压缩的二进制文件代表Redis在某个时间点上的数据快照。非常适用于备份全量复制等场景比如每6小时执行bgsave备份并把RDB文件复制到远程机器或者文件系统中用于灾备。Redis加载RDB恢复数据远远快于AOF的方式。
RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork创建子进程属于重量级操作频繁执行成本过高。RDB文件使用特定二进制格式保存Redis版本演进过程中有多个RDB版本兼容性可能有风险。AOF
类似于mysql的binlog就会把用户的每个操作都记录到文件中。
当redis重新启动的时候就会读取这个aof文件中的内容用来恢复数据~
开启aof的时候rdb就不生效了~ 启动的时候不再读取rdb文件内容了~
aof默认一般是关闭状态修改配置文件来开启aof功能~ AOF是一个文本文件. 每次进行的操作都会被记录到文本文件中~
通过一些特殊符号作为分隔符来对命令的细节做出区分~
AOF缓冲区刷新策略 实际上是没有影响的并没有直接影响到redis处理请求的速度~ 1.AOF机制 并非是直接让工作线程把数据写入硬盘而是先写入一个内存中的缓冲区积累一波之后再统一写入硬盘 2.硬盘上读写数据顺序读写的速度是比较快的 随机访问则速度是比较慢的。 AOF是每次把新的操作写入到原有文件的末尾属于顺序写入~
如果把数据写入到缓冲区里本质还是在内存冲呀~ 万一这个时候突然进程挂了或者主机掉点了咋办是不是缓冲区中的数据就丢了 是的缓冲区中没来得及写入硬盘的数据是会丢的~
redis给出了一些选项让程序员根据实际情况来决定怎么取舍~缓冲区的刷新策略 ~ 刷新频率越高性能影响就越大同时数据的可靠性就越高. 刷新频率越低性能影响就越小同时数据的可靠性就越低.
AOF的重写机制
AOF文件持续增长体积越来越大~ 会影响到redis下次启动的启动时间~ redis启动的时候要读取aof文件的内容
注意上述aof中的文件有一些内容是冗余的
redis存在一个机制能够针对aof文件进行整理操作。这个整理就能够剔除其中的冗余操作并且合并一些操作达到给aof文件瘦身这样的效果。 重写机制~
AOF重写机制的触发机制
手动触发调用bgrewriteaof命令自动触发根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机
AOF重写流程 创建子进程fork 父进程仍然负责接收请求. 子进程负责针对aof文件进行重写~
注意重写的时候不关心aof文件中原来都有啥~ 只关心内存中最终的数据状态~
子进程只需要把内存中给当前的数据获取出来以AOF的格式写入一个新的AOF文件中
此处子进程写数据的过程非常类似于RDB生成一个镜像快照~ 只不过RDB这里是按照二进制的方式生成的 AOF重写则是按照AOF这里要求的文本格式来生成的.
子进程写新aof文件的同时父进程仍然在不停的接收客户端新的请求。 父进程还是会写把这些请求产生的AOF数据写入到缓冲区再刷新到原有的AOF文件里~ 子进程这边把aof数据写完之后会通过信号通知一下父进程父进程再把aof_rewrite_buf缓冲区中的内容也写入到新AOF文件里~ 混合持久化
AOF本来是按照文本方式来写入文件的. 但是文本的方式写文件后续加载的成本是比较高的~ redis就引入了“混合持久化”的方式结合了rdb和aof的特点~ 按照aof的方式每一个请求/操作都记录入文件。在触发aof重写之后就会把当前内存的状态按照rdb的二进制格式写入到新的aof文件中。 后续再进行的操作仍然是按照aof文本的方式追加到文件后面。 这个选项为yes就是开启混合持久化。
同时存在aof和rdb快照以谁为主 以aof为主
信号
信号这个东西可以认为是Linux的神经系统~ 进程之间的互相作用 但是Java生态并不鼓励使用多进程模型编程~
信号能表达的信息有限并非像socket这样的方式可以传输任意的数据~ 因此像上述父子进程场景中子进程表达“我干完了”
