深圳龙岗建网站,雨伞设计公司logo,wordpress 文章备份,上海网站空间什么是持久化#xff1f;
由于redis是基于内存操作的轻量型数据库#xff0c;所以如果发生宕机重启这种事情#xff0c;存储的数据就会直接丢失#xff0c;如果在里面存储了没有备份的数据#xff0c;那么确实会对我们的业务造成一定影响。 所以我们要通过持久化的手段
由于redis是基于内存操作的轻量型数据库所以如果发生宕机重启这种事情存储的数据就会直接丢失如果在里面存储了没有备份的数据那么确实会对我们的业务造成一定影响。 所以我们要通过持久化的手段将数据存入磁盘中只要进入了磁盘就不怕主机宕机重启。这部分数据除非主动删除是可以一直存在这就是持久化。
什么场景需要持久化
一般情况下来说我们使用redis只是给数据库加一层防护防止大量的流量直接打到数据库导致数据库宕机进而引发系统整体瘫痪。 在真正的业务处理中大量访问的数据其实都是一些热点数据那么这些热点数据我们做一层缓存就可以拦截大量的流量不需要将请求再发送给数据库。 减少了与数据库的链接也就是减少了大量的IO耗时。 那么也就做到了单次请求的耗时减少自然而然的 QPS就能整体提升。 扯得远了说回到redis在上面的单纯做数据缓存的场景其实是没有必要进行数据持久化。 因为就算系统宕机重启查询不到数据的时候无非是去数据库里面再捞一把重新存入缓存中就可以了这部分数据是天然就在数据库里面持久化过的。
那说了这么多到底什么场景才需要 我给的答案是除非是真的将redis当成所有业务数据的最终存储位置所有的业务流转都是基于redis来操作没有其他任何天然持久化的数据库如mysql、es等等。 这个时候才是一定需要持久化的。 只要是数据可以通过其他手段重新更新到redis中的话就没有必要在redis进行持久化操作。
哦有的朋友可能会说那总有些业务数据是先更新到缓存中然后再更新到数据库中的吧如果这个时间差里面数据丢失了怎么办 对于这种redis是可以做分布式多节点备份主节点宕机了副节点一样会有一份备用数据。
又有朋友说了那如果所有节点都宕机了怎么办 这种场景我们要想一下到底是丢失了多久的数据 从数据进入缓存到数据异步落库这个时间差真的会很久吗如果这个过程中要保证数据100%不丢失的话redis可以做到但是 这个过程的产生的耗时与直接进入数据库还有区别吗 我们使用redis不就是为了提升性能对吧。
可能还有朋友说了那如果真的是比较重要的数据又对性能要求比较高比如最常见的秒杀系统可以是基于reids来处理的如果这个过程中数据丢失了那不就会造成秒杀系统出问题么。 对于这种我只想说如果在推广秒杀的这么重要的时刻还能发生redis宕机的问题最好是转行吧别做商家系统了会赔死的。 这些问题确实是在面试中遇到过
言归正传但是redis既然有这个持久化的功能那一定就是有人会问的我们就来剖析一下
持久化策略
持久化的策略简单来说分为两种AOF 和 RDB AOF是一种热备份就是在我们不断的更新数据的时候他会不断的将我们更新的数据持久化到磁盘中这个基本上时间差就是ms级别的。 缺点就是可能会对我们更新reids产生一定性能上的影响。 RDB是一种定时冷备份就是每隔一段时间将数据整体备份一次备份的间隔期间是不会对我们的请求造成影响。缺点就是在备份的过程中可能会影响我们的更新操作并且会丢失一定时间内的数据。
RDB
全称是Redis Database Backup file直译是redis数据备份我们称之为数据快照。
自动备份 在配置文件中配置需要注意的是这种快照备份是会阻塞redis服务器不能处理其他命令直到备份完成
# 900秒内至少1个键被修改则进行快照
save 900 1# 300秒内至少10个键被修改则进行快照
save 300 10# 60秒内至少10000个键被修改则进行快照
save 60 10000手动备份 执行命令bgsave 这个命令是手动开启一个子进程过程中不会阻塞其他的reids命令
RDB备份的流程 备份数据的时有一个fork(创建)一个子进程的动作将主进程中的所有内容全部复制然后进行一个数据复制备份的操作这个fork是什耗费时间的。 所以如果性能要求比较高的话建议可以关闭默认的save在服务器上用shell写一个定时器每天的固定时间去执行bgsave命令可以提高系统的性能。缺点就是可能会丢失一定的数据。
AOF
全称是Append Only File 是一个命令追加保存的策略。 将每个命令都存储到aof文件中恢复数据的时候是进行命令回放来。
AOF的配置参数
appendonly是否开启AOF持久化策略默认为no。appendfilenameAOF文件的名字默认为appendonly.aof。appendfsyncAOF文件的同步模式有always、everysec、no三种模式。no-appendfsync-on-rewrite在AOF重写时是否停止同步默认为no。auto-aof-rewrite-percentageAOF文件长度增长的百分比超过该百分比进行AOF文件重写。默认100auto-aof-rewrite-min-sizeAOF文件重写触发的最小文件体积。默认64mb
同时开启aof和rdb策略的话优先使用aof
备份流程
客户端发送写操作命令给Redis服务器。服务器接收到命令将其写入内存中并将该命令添加到AOF缓冲区。AOF缓冲区根据策略可能会被同步到硬盘上的AOF文件中。Redis服务器定期检查AOF文件的大小并进行AOF重写操作即压缩AOF文件。如果Redis服务器异常会从AOF文件中读取命令进行数据恢复。
AOF重写操作 aof rewrite 设置了auto-aof-rewrite-percentage或者auto-aof-rewrite-min-size会触发重写操作。 size配置很清晰意思是超过多大就要重写。 percentage的意思是本次的文件大小和上次的文件大小对比超过百分之多少就进行重写。
为什么要重写aof文件 因为命令是不断接收的所以文件肯定也是不断的增大如果过大的话一定会对cpu造成负担IO性能下降内存消耗过大。所以就要进行文件瘦身操将命令梳理一遍。 比如已经del的数据那所相关的命令肯定就没有存在的必要了。
重写的时候也是fork出来一个子进程然后扫描当前reids所有的键值对生成一份新的aof文件。 这个过程中redis是没有阻塞还在不断的接收新的命令这些新的命令会存在aof缓冲区等到新的aof完成的话再将这些新命令存入新的aof文件中
总结
最优的持久化手段就是AOF和RDB配合使用因为AOF文件命令恢复数据是比较慢的。
定时的通过shell来进行定时的rdb快照备份。然后再通过aof文件来进行缺失数据的补充。
