Redis学习11：持久化RDB/AOF

持久化简介

• 什么是持久化？
• 利用永久性的存储介质进行保存，特定的时间将保存的数据进行恢复。
• 持久化方式：保存分为快照和日志。注意日志保存的是整个操作的过程。

• 在Redis中两种都有，左边叫做RDB，右边叫做AOF。

RDB 快照

• RDB启动方式
• 一定要有三个因素：任务时间地点

• 对应命令：sava
• 每执行一次就可以手动保存一次数据
• 先通过 key * 查看有没有数据
• 有没有数据 没有就添加
• 然后save命令
• 然后进入到data目录下会发现 dump.rdb 一个文件
• 打开rdb文件发现乱码，是因为rdb是二进制文件所以查看不出来

• 把rdb删掉，然后再执行一次save，然后查看会发现又有了rdb文件。
• 每保存一次，会 生成一个rdb文件生成当前的快照信息。

RDBsava指令的相关配置

• 进入data目录中，查看dump.rdb文件。
• 然后可以通过更改配置文件来修改save的相关命令
• 进入到目录中，cat conf文件，进行更改配置

• 然后重新开启一下这个进程，先kill -s 这个进程
• 然后redis-server conf/redis-6379.conf 启动redis就可以生效了
• 然后就可以通过save命令后直接去data目录下查看有没有这个文件

• 先杀掉这个进程，然后再次启动这个服务，看是否恢复了数据 。

• 通过命令：redis-server conf/redis-6379.conf 启动
• 可以通过：ps -ef | grep redis- 来查看有哪些进程
• 通过客户端连接 然后keys * 查看到原来的数据恢复了
• 原理是在启动的时候把数据加载了进行恢复

save的工作原理

• 要注意redis是单线程执行。

• 注意save的指令可能会阻塞redis服务器，线上环境不建议使用，因为会把性能损耗很多。
• 所以需要慎重需要使用RDB线上的使用。
• 总结：当数据量过大，rdb单线程执行方式造成的效率过低，性能过低。
• 解决方案：rdb后台执行。

• bgsave 就是命令了。
• 手动启动后，后台将保存这个操作，但不是立即就执行了。

• 执行ll查看rdb的大小与时间。

• 工作原理：

• 那么如何验证这个工作过程呢？
• 可以进行查看日志文件，来查看是否是这样的。
• cat 6379.log
• 可以查看到日志也是这么显示的。

bgsave与save总结

• bgsave命令是针对save阻塞问题做的优化，redis内部涉及到的rdb操作都将采用bgsave的方式，save命令可以放弃使用的。

自动执行save rdb启动方式

• 意思就是说，10s内有99个key了，那么就需要进行持久化。其实就是单位时间内达标了就进行bgsave存。
• 配置的方式和案例如下：

rdb三种启动方式对比

• bgsave起了一个新进程所以需要额外的内存消耗的。

第二种持久化方案 AOF

RDB存储的弊端：

• 最后一个指的是无法时刻进行RDB，可能会有一些丢失。

AOF介绍

AOF写数据的过程

• 那么问题变成了如何控制命令同步到.aof文件中。
• 一共有三种策略：
• 每次、每秒、系统控制

AOF功能开启

• 进入到conf目录下，然后更改conf文件就可以了。
• 配置过程如下：

• 然后到客户端写一个set name 123，会发现.aof文件已经开始变化了。

• 也就是说always是可以每次都记住变化的。
• 但是记住如果是get，.aof的大小是不会变化的，因为没有进行更改数据。
• 然后可以查看这个文件。

• 如果改成 everysec的话是看不出来每次一存的区别的。因为每秒一存太快了。

AOF重写概念与命令执行

• bg就是后台的意思，background。

• 当执行重写之后，再次查看ll。然后发现变小了。

• 发现只剩下了345。
• 类似消消乐，多个操作合并一个了。

自动AOF重写

• 一共有两种，一个是大小，一个是百分比。
• 这个两个触发条件触发一个就会触发AOF了。
• 在客户端输入info就可以看到上面说的系统数据值了。

AOF的工作流程

RDB与AOF的区别

• RDB类似整盘复制。

• 比如说游戏的回档，玩家是可以接受的。所以可以用RDB，用来做阶段性的恢复。
• 如果用了RDB，那么存储的时间要慎重考虑。

持久化的应用场景

• 第一个主键id不适合用持久化，适合临时化。
• 第二个热度数据也不适用。
• 第三个不适用。因为数据库也有。
• 第四个快速存储、快速消失的适合存起来。其次恢复这个就不用后台做大规模的重做。如果差一两个，那么激活码就多发一两个也没事。
• 第五个操作先后顺序的话也适用redis存储。
• 任务队列、消息队列也可以，但是用MQ更适合。
• 第七个关联搜索不适用。
• 黑白名单的控制：如果黑名单做的是长期策略，那么数据库肯定要存，就不需要redis了。而如果是短期策略，那么就不适合。（因为网吧或者校园网的ip进行黑名单了，那么如果直接封了网吧和校园网会导致其他的用户ip访问不了了。）
• 排名功能适合做持久化，这种数据是不会存数据库的。
• 最后一个应用按次结算，那么要不要持久化，可以这么想：如果不存，会不会出灾难性的结果，如果会出现，那么需要，如果不会出现，那么就不用管。