持久化简介
什么是持久化？
利用永久性的存储介质进行保存，特定的时间将保存的数据进行恢复。
持久化方式：保存分为快照和日志。注意日志保存的是整个操作的过程。
在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访问不了了。）
排名功能适合做持久化，这种数据是不会存数据库的。
最后一个应用按次结算，那么要不要持久化，可以这么想：如果不存，会不会出灾难性的结果，如果会出现，那么需要，如果不会出现，那么就不用管。
