持久化简介
- 什么是持久化？
- 利用永久性的存储介质进行保存，特定的时间将保存的数据进行恢复。
- 持久化方式：保存分为快照和日志。注意日志保存的是整个操作的过程。
- 在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起了一个新进程所以需要额外的内存消耗的。
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类似整盘复制。
- 比如说游戏的回档，玩家是可以接受的。所以可以用RDB，用来做阶段性的恢复。
- 如果用了RDB，那么存储的时间要慎重考虑。
- 第一个主键id不适合用持久化，适合临时化。
- 第二个热度数据也不适用。
- 第三个不适用。因为数据库也有。
- 第四个快速存储、快速消失的适合存起来。其次恢复这个就不用后台做大规模的重做。如果差一两个，那么激活码就多发一两个也没事。
- 第五个操作先后顺序的话也适用redis存储。
- 任务队列、消息队列也可以，但是用MQ更适合。
- 第七个关联搜索不适用。
- 黑白名单的控制：如果黑名单做的是长期策略，那么数据库肯定要存，就不需要redis了。而如果是短期策略，那么就不适合。（因为网吧或者校园网的ip进行黑名单了，那么如果直接封了网吧和校园网会导致其他的用户ip访问不了了。）
- 排名功能适合做持久化，这种数据是不会存数据库的。
- 最后一个应用按次结算，那么要不要持久化，可以这么想：如果不存，会不会出灾难性的结果，如果会出现，那么需要，如果不会出现，那么就不用管。
