Redis的两种持久化方式-快照持久化（RDB）和AOF持久化

Redis为了内部数据的安全考虑，会把本身的数据以文件形式保存到硬盘中一份，在服务器重启之后会自动把硬盘的数据恢复到内存(redis)的里边，数据保存到硬盘的过程就称为“持久化”效果。

redis有两种持久化功能，一种是“快照持久化（RDB）”,一种是“AOF持久化”。

RDB的缺点：耗时、耗性能、耗内存。不可控，容易丢失数据

1.snap shotting快照持久化

该持久化默认开启，一次性把redis中全部的数据保存一份存储在硬盘中，如果数据非常多(10-20G)就不合适频繁操作该持久化操作。

如果对redis有数据操作，就会根据redis的配置文件指定的文件名和路径生成rdb文件，先来看一下redis配置方面的截图说明



再看一下在redis目录下生成的rdb文件



可以使用vim命令对dump.rdb文件编辑看一下内容



注意：如果您细心的发现，在对redis客户端进行数据操作之后，再次进行对dump.rdb文件进行编辑查看，文件中可能会缺少最近的操作记录，这与配置文件中备份的频率有关，下面看一下截图

save 900 1             #900 秒内如果超过 1 个 key 被修改，则发起快照保存
save 300 10            #300秒超过10个key被修改，发起快照
save 60 10000            #60秒超过10000个key被修改，发起快照

以上三个save的意思都有了相应的说明，数据修改的频率非常高，备份的频率也高，数据修改的频率低，备份的频率也低。

如果发现dump.rdb文件缺少了最近的记录，那么在这补充一种手动持久化方式，可以立即看到效果，执行此命令

./redis-cli bgsave          #异步保存

其次还包括一些其他的手动命令

./redis-cli shutdown    #同步保存到服务器并关闭redis服务器
./redis-cli lastsave    #返回上次成功保存到磁盘的unix时间戳
./redis-cli bgrewriteaof  #当日志文件过长时优化AOF日志文件存储

由于快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用aof持久化方式

2.append only file(AOF持久化)

AOF持久化本质:把用户执行的每个“写”指令(添加/修改/删除)都备份到文件中，还原数据的时候就是执行具体写指令而已。

开启AOF持久化(会清空redis内部的数据，最好在redis使用之前就开启它)

我们在redis.conf配置文件中可以找到它:



修改完成配置之后重启redis





再次启动测试一下是否有数据



看一下目录下自定义的aof文件，目前得大小是0



操作之后



vim查看一下



所有指令全部写入文件

在redis.conf中，可以调整AOF备份形式:

always          一写指令就备份一次。这样做虽然安全，但是系统性能会降低。不推荐使用
everysec         每一秒中备份一次。不管一秒钟变化了多少key，只备份一次，性能得到一定的保护。推荐使用。
no            会查看当前服务器状态，如果状态良好，就进行备份(随机)。这种备份方式数据是没有保证的。

对比下来，性能:always<everysec<no，而数据安全:always>everysec>no。

举例说明一下，这里就暂时不操作了，您可以拿redis的自增来操作：incr num ，执行此命令10次，然后查看一下aof文件，发现aof文件保存的是最终的数值，而且是set命令，这样就节省了空间，下面说一下就是把AOF备份文件中所有的备份数据的内容进行一个处理。

在启动redis客户端的时候，使用bgrewriteaof指令，就可以对aof备份文件的内容进行

优化压缩处理。截图对比一下处理先后的大小



完毕