一文带你了解Redis持久化完整版本

']本文讲解知识点持久化的简介RDBAOFRDB与AOF的区别持久化应用场景'^前言']咔咔整理了一个路线图，打造一份面试宝典，准备按照这样的路线图进行编写文章，后期发现没有补充到的知识点在进行添加。也期待各位伙伴一起来帮助补充一下。评论区见哦！'^在这里插入图片描述演示环境centos7.0redis4.0redis存放目录：/usr/local/redisredis.conf存放目录：/usr/local/redis/data1. 持久化简介redis的所有数据都是保存在内存中，redis崩掉数据会丢失。redis持久化就是把数据保存在磁盘上。利用永久性存储介质将数据进程保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。

持久化过程保存的是什么呢？

第一种快照形式，存储数据结果，关注点在数据，也就是下文会讲到的RDB

第二种操作过程，存储操作过程，存储结构复杂，关注点在数据的操作过程，也就是下文会讲到的AOF2. RDB2-1 RDB启动方式--save命令下图是redis.conf的配置信息，在执行完save后会生成一个dump.rdb的文件现在我们设置一个值，然后save一下，在/usr/local/redis/data下就会有一个dump6379.rdb的一个文件2-2 RDB启动方式--save指令相关配置dbfilename dump6379.rdb ：设置本地数据库文件名，默认值为dump.rdbdir：存储rdb文件的路径rdbcompression yes ：设置存储至本地数据库时是否压缩数据，默认为yes，采用lzf压缩rdbchecksum yes：设置是否进程RDB文件格式校验，该校验过程在写文件和读文件过程均进行2-3 RDB数据恢复其实这个数据恢复相对于其他关系型数据库恢复基本就不用操作什么。只需要重新在启动就好了2-4 RDB -- save指令工作原理此图来源于网络视频。save指令的执行会阻塞当前redis服务器，直到当前RDB过程完为止，有可能会造成长时间的阻塞。这个指令在工作过程中基本以被废弃不在使用。会以bgsave全部代替2-5 RDB -- bgsave指令工作原理当在redis执行了bgsave后会直接返回一个Background saving started

这个时候我们在看一下日志文件，bgsave命令是针对save阻塞问题做的优化2-5 RDB -- 配置文件自启动save 900 1save 300 10save 60 10000stop-writes-on-bgsave-error yessave【时间】 【key改变数量】

也就是说在300秒有10个key值发生变化了，就会在后台执行bgsave3. AOF3-1 AOF概念AOF持久化：以独立日志的方式记录每次写命令，重启时在重新执行AOF文件中命令达到数据恢复的目的。与RDB相比可以简单描述为记录数据产生的过程

AOF的主要作用是解决了数据持久化的实时性，目前已经是redis持久化的主流方式3-2 AOF写数据过程执行一条redis命令

redis的AOF会把命令刷新缓冲区

然后根据一定的策略同步的到redis.conf配置的.aof文件中3-3 AOF写数据的三种策略always：每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用everysec：每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置。但是在系统突然宕机的情况下回丢失1秒内的数据no：由操作系统控制每次同步到AOF文件的周期，整体过程不可控3-4 AOF功能开启配置：appendonly yes|no作用：是否开启AOF持久化功能，默认为不开启状态配置：appendfsync always| everysec | no作用：AOF写数据策略配置：appenfilename filename作用：AOF持久化文件名，默认名为appendonly.aof然后使用重启redis服务，就可以在usr/local/redis/data目录下可以看到appendonly.aof文件了然后我们在redis客户端执行一条命令，在来查看一下。可以看到数据都会存入appendonly.aof这个文件中。3-5 AOF写数据出现的问题我们先看一个案例，我们重复设置了name这个key后，打开appendonly.aof文件查看，可以看到有三个操作，但是这三个操作我们都是修改的一个key啊！我们只保存最后一个key不行吗？带着这个疑问，我们在继续往下看3-6 AOF重写随着命令不断写入AOF，文件会越来越大，为了解决这个问题，redis引入了AOF重写机制压缩文件体积。AOF文件重写是将redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干条命令执行结果转化为最终结果数据对应指令的执行记录。

如在上边我们执行了三次setname指令，但是我们最终就只需要最后一次执行的数据。也就是我们只需要最后一次执行记录即可。3-7 AOF重写作用降低磁盘占用量，提高磁盘利用率提高持久化效率，降低持久化写时间，提高IO性能降低数据恢复用时，提高数据恢复效率3-8 AOF重写规则进程内已超时的数据不再写入文件忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件值保留最终数据的写入命令。如del指令，hdel，srem。多次设置一个key值等对同一数据的多条写入命令合并为一条命令：如lpush list a lpush lsit b lpush list c可以转化为lpush list a b c。但是为了防止数据量过大造成客户端缓冲区溢出，对list，set，hash，zset类型每条指令最多写入64个元素3-9 AOF手动重写指令：bgrewriteaof

接着我们3-5的问题，我们在命令行执行bgrewriteaof指令然后查看appendonly.aof文件

当执行完后会发现文件变小了，文件里也就只有一条指令了在这里插入图片描述3-10 AOF手动重写工作原理在这里插入图片描述3-11 AOF自动重写配置：auto-aof-rewrite-percentage 100 | auto-aof-rewrite-min-size 64mb触发对比参数：aof_current_size | aof_base_size

当aof_current_size>auto-aof-rewrite-min-size 64mb会启动重写

此图来源于网络3-11 AOF工作流程和重写流=流程4. RDB和AOF区别对数据非常敏感，建议使用默认的AOF持久化方案AOF持久化策略使用everysecond, 每 秒 钟fsync-次 "该策略redis仍可以保持很好的处理性能，当出现问题时， 最 多丢失0-1秒内的数据.注意：由于AO文件存储体积较大，且恢复速度较慢数据呈现阶段有效性，建议使用RDB持久化方案数据可以良好的做到阶段内无N失（该阶段是开发者成运维人手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案注 意 ： 利 用RDB实现紧促的数据持久化会使Redis降的很低综合对比RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊如不能承受数分钟以内的数据丢失，对业努数据非常敏感，选用A0F如能承受数分钟以内的数据N失，旦追求大数据集的恢复速度，选用RDB灾难恢复使用RDB双保险策略，同时^u启RDB和AOF, 重启后，Redis优先使用A0F来恢复数据，降低丢失数据的量']坚持学习、坚持写博、坚持分享是咔咔从业以来一直所秉持的信念。希望在偌大互联网中咔咔的文章能带给你一丝丝帮助。我们下期再见。'^推荐：《redis教程》以上就是一文带你了解Redis持久化完整版本的详细内容，更多请关注小潘博客其它相关文章！