虚拟主机网站建设步骤?,市文联网站建设,wordpress菜单前图标,网站建设合同有效期前言Redis是出了名的速度快#xff0c;那是因为在内存中进行数据存储和操作#xff1b;如果仅仅是在内存中进行数据存储#xff0c;那就会导致以下问题#xff1a;•数据随进程退出而消失#xff1a;当服务器断电或Redis Server进程退出时#xff0c;内存肯定随之释放那是因为在内存中进行数据存储和操作如果仅仅是在内存中进行数据存储那就会导致以下问题•数据随进程退出而消失当服务器断电或Redis Server进程退出时内存肯定随之释放最后数据也会丢失可能有些小伙伴认为只是作为缓存数据没有了重新从数据库中读取放在里面即可试想如果是高并发场景数据库岂不是压力很大•重要数据无法恢复数据丢失之后无法进行恢复对于一些重要的数据只是存在Redis中而没有存在关系型数据库如果数据丢失便不可恢复比如刷礼品排行榜如果数据丢失用户肯定不愿意的对于Redis持久化在工作中和面试过程中是一个很重要的技术点必用必考接下来详细说说Redis持久化正文Redis针对数据持久化有两种方案如下•RDB(Redis DataBase)快照形式即指定时间间隔将Redis内存中的快照数据保存在物理磁盘上数据保存在*.rdb文件中以二进制的形式进行存储恢复数据直接加载即可•AOF(Append Only File)日志形式即将每条写命令以append-only模式记录在*.aof文件中不能修改文件只能进行追加后续恢复数据自动执行日志文件中的命令即可恢复数据•混合就是RDB和AOF的结合以上方式都可以通过配置文件轻松搞定来咱们先从RDB开始fork后续会频繁提到简单解释一下fork的作用是复制一个与当前进程一样的子进程该子进程的所有数据都和原进程一致。RDB持久化理论放到后面再说先来看看实际操作再来做总结上次对配置文件简单进行说明这次就直接找到快照那配置就行啦先看看默认配置通过 save seconds changes进行条件配置如果触发条件就自动进行RDB持久化操作。默认配置中包含以下三种条件满足其中一个就自动保存数据到磁盘•save 900 1900秒内(15分钟)至少有1个key的值进行修改•save 300 10300秒内(五分钟)至少有10个key的值进行修改•save 60 10000900秒内(1分钟)至少有10000个key的值进行修改测试验证为了测试时间方便将其中一个条件改为1分钟内有3个key的值修改了就进行持久化到磁盘如下1.先将原有的dump.rdb文件删除掉避免影响测试效果2.修改配置文件如下3.用修改之后指定该配置文件重启redis-server然后开始测试4.尝试打开dump.rdb看看咋一看是看不懂但其实是有对应关系的这里就不深究了Redis强大吧不知不觉的就把数据备份主要是还不影响正常操作上图中第四步中就有体现主进程fork了子进程进行备份主进程不参与备份持久化操作。既然备份文件有了如何进行恢复数据呢 redis-server在启动的时候自动将当前目录中的备份文件(dump.rdb)数据加载到内存中如下图所示RDB其他配置项那为什么是dump.rdb文件为什么又是当前目录如果rdb备份文件写入失败了怎么办这些通过配置文件中SNAPSHOTTING部分都有详细的说明并提供相关配置项进行设置如下•stop-writes-on-bgsave-error默认设置为yes即当RDB备份数据失败时Redis会停止接收数据保证数据的一致性如果对数据一致性要求不高的可以将其进行关闭设置为no但推荐都开启•rdbcompression默认设置为yes开启压缩之后会采用LZF算法对备份文件dump.rdb进行压缩但会消耗点CPU性能进行处理但影响并不大推荐都开启•rdbchecksum默认设置为yes即开启之后会对备份文件数据进行校验但会消耗CPU性能如果追求性能提高可以将其关闭但影响也不大推荐都开启•dbfilename默认为dump.rdb即默认的备份文件名为dump.rdb可以通过这个配置进行修改•dir默认为当前目录即备份的文件存放的目录。RDB手动触发备份上面说到自动触发备份其实在实际应用场景中有些需求很急如果要求等到满足条件备份完成之后才处理问题间隔时间短还好点如果间隔时间超过5分钟估计等待处理问题的人要上房揭瓦啦Redis同样为大家考虑到了提供手动备份的方式如下•save直接执行save命令但会阻塞主进程操作只能等待备份完成之后才能进行其他处理•bgsave直接执行bgsave命令主进程会fork一个子进程进行备份操作不阻塞主进程当数据过大时可能会在fork的时候有短暂的耗时但影响不大上面的自动备份其实最后也是bgsave这种模式。•flushall执行flushall命令会触发RBD备份但是备份文件是空的在本地测试一把就行了没有任何意义千万别在生产库上用简单测试一下删除dump.rdb文件将配置文件恢复到默认值然后指定配置文件重启redis-server如下如何停止或禁用RDB快照自动备份可以通过配置文件的形式配置也可以通过命令的形式进行关闭但通过命令的方式服务器重启之后就失效了所以一般建议通过配置文件进行配置•配置文件方式去除所有关于save的配置或者配置一个save 即可重启redis-server•命令方式在客户端中执行config set save 即可但redis-server重启时就恢复默认值了RDB备份流程简要说明1.当触发bgsave持久化时(满足配置条件或手动执行bgsave命令)主进程fork一个子进程进行持久化操作主进程不参与任何持久化IO操作2.为了不影响原有rdb文件的使用子进程会将快照数据先写入到临时文件;3.当快照数据完全备份到临时文件时就替换掉原有的rdb文件从而得到最新数据的rdb文件注当执行sava命令的时候会导致阻塞只有等快照数据持久化完成之后才能做其他事情RDB持久化优缺点每一项技术在解决已有问题的时候肯定也会带来新问题RDB用来解决持久化问题那它有什么优缺点呢优点•RDB保存的数据文件比较紧凑对比AOF来说相同数据的文件大小比较小•大量数据持久化时速度相对AOF比较快•RDB中bgsave模式对主进程影响比较小只有在主进程fork子进程的时候耗费资源但影响不大自动备份后台用的就是bgsave模式缺点•RDB可能会丢失最后一次没有备份的数据如果在最后一次没开始备份之前服务器挂了那最后一次的数据就没了•当数据量巨大时主进程在fork子进程的时候可能会导致稍微的卡顿AOF持久化既然已经有了RDB持久化了那为什么还得出一个AOF呢从RDB的缺点来看很大程度上是因为可能会丢失最后一次备份之前的数据对于一些重要数据来说是不能接受的。而AOF的出现将数据丢失风险极大的降低。先不说那么多实操一把再慢慢聊。AOF默认情况是没开启的打开配置文件为了不让RDB备份影响这里暂时先将RDB备份禁用掉如下1.禁用RDB备份1.开启AOF备份根据上一篇文章提到的先找到APPEND ONLY MODE配置块将AOF备份开启appendonly yes2.配置好了指定配置文件重启redis-server先来看看效果当一启动redis-server的时候appendonly.aof文件就已经生成了来咱们接着敲点命令如下↓↓↓3.尝试打开appendonly.aof文件看看和dump.rdp文件有什么不同appendonly.aof只记录写命令读命令不记录而且记录方式是以追加的方式所以速度相对比较快同RDB一样在redis-server重启时自动加载AOF文件命令依次执行最终将数据进行恢复AOF其他配置项这就是Redis的强大针对每一个功能都可以通过配置项进行完成使用非常方便•appendonly默认no不开启AOF持久化可以通过设置为yes开启•appendfilename默认appendonly.aof代表生成的AOF日志文件名可以更改•appendfsync默认everysec设置同步命令到磁盘的策略即默认每秒通过fsync进行一次命令同步到磁盘有三种命令同步策略可以选择如下1.always只要有写入命令就通过fsync同步到磁盘数据完整性好但效率不好2.everysec每秒通过fsync进行一次命令同步到磁盘可能会导致一秒中数据的丢失因为可能在命令还没同步的时候机器挂掉等操作但可接受综合考虑推荐使用这种策略3.no不同步由操作系统处理这种数据不能保证安全•auto-aof-rewrite-percentage默认100搭配auto-aof-rewrite-min-size一起触发AOF文件重写策略即默认当当前AOF文件大小是上次重写的两倍时才重写为了避免比率达到触发条件但文件很小就触发重写的情况所以搭配auto-aof-rewrite-min-size设置AOF文件的最小重写大小即当前AOF文件大小达到比率的同时文件大小不低于auto-aof-rewrite-min-size设置的值才触发重写•auto-aof-rewrite-min-size默认64mb搭配auto-aof-rewrite-percentage使用AOF触发重写当执行的写命令过多时就会导致AOF文件过度增大而对于一些重复性的命令存在AOF文件中是没有必要的如下图所示上图中多次对a1这个Key进行多次写入最终的值为10可见如果AOF文件中只记录一条最终值的写命令岂不是最好从而减少AOF文件的大小这里文件大小肯定达不到自动触发重写的条件这里就手动触发然后再看看AOF文件内容是否进行了优化如下如上图可见重写之后的AOF文件的确是我们自己想要是不是觉得Redis更加牛X了触发重写有以下两种方式•自动触发即当满足设置的auto-aof-rewrite-percentage和auto-aof-rewrite-min-size值会自动触发重写•手动触发在客户端中执行bgrewriteaof命令AOF重写流程简要说明1.当触发到重写AOF文件时主进程fork一个子进程子进程根据内存中的现有数据进行命令精简化重写到新的AOF文件中2.在子进程正在重写AOF文件时如果有新的写命令将其存放到重写缓冲区同时也同步到原来的AOF文件3.当子进程重写完成之后通知主进程将重写缓冲区中的新命令写入到新AOF文件中完成之后用新的AOF文件将原来的AOF文件替换4.最后得到优化之后的AOF文件减少文件大小AOF文件修复对于AOF文件内容的合法性怎么解决呢有可能由于突然事件比如宕机导致AOF文件写入不完整也有可能有人恶意添加不规范数据redis会怎么处理呢这里就模拟手动修改AOF文件如下根据提示使用redis-check-aof --fix filename进行修复如下启动图就不截了小伙伴们试试去还有redis也能对rdb文件修复文中没有体现但小伙伴记得去尝试一下用redis-check-rdb这个工具即可在windows版本中redis没有提供此工具去linux用高点的版本实操一把。AOF持久化优缺点AOF的出现是解决了RDB丢失最后一次没保存的数据极大的降低了数据丢失的风险但其也带来相关问题优点•降低数据丢失风险如果丢失最多一秒数据•以追加方式记录日志速度快•自动优化AOF文件文件过大时进行重写精简AOF文件缺点•相同大数据AOF文件比RDB文件大占用磁盘空间•对于大数据的恢复速度没有RDB快混合持久化在redis4.0之后提供了混合持久化配置开启功能混合持久化就是结合RDB和AOF各自优点进行整合的持久化方案从而解决使用AOF恢复数据较慢的问题原理就是在AOF文件的前半段加入RDB快照数据后面才是增量数据的命令记录在配置文件中进行配置即可aof-use-rdb-preamble yes高版本redis都默认开启这种混合持久化模式优点解决了单纯AOF恢复数据较慢的问题缺点不能兼容低版本redis场景选择哪个持久化比较合适如果需求对数据完整性要求不是很高可以接受短时间数据丢失RDB快照持久化方式是最好不过的选择如果对数据完整性要求比较严格使用AOF日志形式进行持久化比较合适如果redis版本在4.0以上可以使用混合持久化的方式降低纯AOF文件的恢复数据的时间如果仅仅是缓存缓存数据也不重要并发也不是很高可以不用开启持久化注如果不是使用混合持久化而是将RDB和AOF同时开启redis-server恢复数据的时候会优先使用AOF文件进行数据恢复因为AOF文件相对比较完整总结暂时就到这吧后续遇到相关问题再来记录分享这个知识点比较重要所以小伙伴们一定要自己尝试一下哦使用真的很简单进行简单的配置就完事了如果能知道其简单的原理遇到问题就没那么苦恼下次我们来聊redis的主从复制一个被程序搞丑的帅小伙关注Code综艺圈跟我一起学~
