06.论Redis持久化的几种方式

📝 个人主页：程序员阿红🔥
👑 生活平淡，用心就会发光，岁月沉闷，跑起来，就会有风
📣 推荐文章：
📚📚📚 【毕业季·进击的技术er】忆毕业一年有感
📚📚📚 Java 学习路线一条龙版
📚📚📚 一语详解SpringBoot全局配置文件

1. RDB

Redis DataBase

• 在指定的时间间隔内，将内存中的数据集的快照写入磁盘；
• 默认保存在/usr/local/bin中，文件名dump.rdb;

1.1 自动备份

• redis是内存数据库，当我们每次用完redis，关闭linux时，按道理来说，内存释放，redis中的数据也会随之消失
• 为什么我们再次启动redis的时候，昨天的数据还在，并没有消失呢？
• 正是因为，每次关机时，redis会自动将数据备份到一个文件中 ：/usr/local/bin/dump.rdb
• 接下来我们就来全方位的认识 自动备份机制

1. 默认的自动备份策略不利于我们测试，所以修改redis.conf文件中的自动备份策略

vim redis.conf
/SNAP  # 搜索
save 900 1   # 900秒内，至少变更1次，才会自动备份
save 120 10 # 120秒内，至少变更10次，才会自动备份
save 60 10000 # 60秒内，至少变更10000次，才会自动备份

当然如果你只是用Redis的缓存功能，不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。可以直接一个空字符串来实现停用：save “”

1. 使用shutdown模拟关机 ，关机之前和关机之后，对比dump.rdb文件的更新时间

注意：当我们使用shutdown命令，redis会自动将数据库备份，所以，dump.rdb文件创建时间更新了

1. 开机启动redis，我们要在120秒内保存10条数据，再查看dump.rdb文件的更新时间（开两个终端 窗口，方便查看）
2. 120秒内保存10条数据这一动作触发了备份指令，目前，dump.rdb文件中保存了10条数据，将 dump.rdb拷贝一份dump10.rdb，此时两个文件中都保存10条数据
3. 既然有数据已经备份了，那我们就肆无忌惮的将数据全部删除flushall，再次shutdown关机
4. 再次启动redis，发现数据真的消失了，并没有按照我们所想的 将dump.rdb文件中的内容恢复到redis中。为什么？

因为，当我们保存10条以上的数据时，数据备份起来了；
然后删除数据库，备份文件中的数据，也没问题；

但是，问题出在shutdown上，这个命令一旦执行，就会立刻备份，将删除之后的空数据库生成备份文件，将之前装10条数据的备份文件覆盖掉了。所以，就出现了上图的结果。自动
恢复失败。

怎么解决这个问题呢？要将备份文件再备份

1. 将dump.rdb文件删除，将dump10.rdb重命名为dump.rdb
2. 启动redis服务，登录redis，数据10条，全部恢复！

1.2 手动备份

• 之前自动备份，必须更改好多数据，例如上边，我们改变了十多条数据，才会自动备份；
• 现在，我只保存一条数据，就想立刻备份，应该怎么做？
• 每次操作完成，执行命令 save 就会立刻备份

1.3 与RDB相关的配置

• stop-writes-on-bgsave-error：进水口和出水口，出水口发生故障与否 - yes：当后台备份时候反生错误，前台停止写入- no：不管死活，就是往里怼
• rdbcompression：对于存储到磁盘中的快照，是否启动LZF压缩算法，一般都会启动，因为这点性能，多买一台电脑，完全搞定N个来回了。 - yes：启动- no：不启动（不想消耗CPU资源，可关闭）
• rdbchecksum：在存储快照后，是否启动CRC64算法进行数据校验； - 开启后，大约增加10%左右的CPU消耗；- 如果希望获得最大的性能提升，可以选择关闭
• dbfilename：快照备份文件名字 dir：快照备份文件保存的目录，默认为当前目录

优势and劣势

• 优：适合大规模数据恢复，对数据完整性和一致行要求不高；
• 劣：一定间隔备份一次，意外down掉，就失去最后一次快照的所有修改

2. AOF

Append Only File

• 以日志的形式记录每个写操作；
• 将redis执行过的写指令全部记录下来（读操作不记录）；
• 只许追加文件，不可以改写文件；
• redis在启动之初会读取该文件从头到尾执行一遍，这样来重新构建数据；

2.1 开启AOF

1. 为了避免失误，最好将redis.conf总配置文件备份一下，然后再修改内容如下：

appendonly yes
appendfilename appendonly.aof

1. 重新启动redis，以新配置文件启动

redis-server /usr/local/redis5.0.4/redis.conf

1. 连接redis，加数据，删库，退出
2. 查看当前文件夹多一个aof文件，看看文件中的内容,保存的都是 写 操作1. 文件中最后一句要删除，否则数据恢复不了2. 编辑这个文件，最后要 :wq! 强制执行
3. 只需要重新连接，数据恢复成功

2.2 共存？谁优先？

我们查看redis.conf文件，AOF和RDB两种备份策略可以同时开启，那系统会怎样选择？

1. 动手试试，编辑appendonly.aof，胡搞乱码，保存退出
2. 启动redis 失败，所以是AOF优先载入来恢复原始数据！因为AOF比RDB数据保存的完整性更高！
3. 修复AOF文件，杀光不符合redis语法规范的代码

reids-check-aof --fix appendonly.aof

2.3 与AOF相关的配置

• appendonly：开启aof模式
• appendfilename：aof的文件名字，最好别改！
• appendfsync：追写策略 - always：每次数据变更，就会立即记录到磁盘，性能较差，但数据完整性好- everysec：默认设置，异步操作，每秒记录，如果一秒内宕机，会有数据丢失- no：不追写
• no-appendfsync-on-rewrite：重写时是否运用Appendfsync追写策略；用默认no即可，保证数据安全性。 - AOF采用文件追加的方式，文件会越来越大，为了解决这个问题，增加了重写机制，redis会自动记录上一次AOF文件的大小，当AOF文件大小达到预先设定的大小时，redis就会启动AOF文件进行内容压缩，只保留可以恢复数据的最小指令集合
• auto-aof-rewrite-percentage：如果AOF文件大小已经超过原来的100%，也就是一倍，才重写压缩
• auto-aof-rewrite-min-size：如果AOF文件已经超过了64mb，才重写压缩

3 总结（如何选择？）

• RDB：只用作后备用途，建议15分钟备份一次就好
• AOF： - 在最恶劣的情况下，也只丢失不超过2秒的数据，数据完整性比较高，但代价太大，会带来持续的IO- 对硬盘的大小要求也高，默认64mb太小了，企业级最少都是5G以上；- master/slave才是新浪微博的选择！！

💖💖💖 完结撒花

💖💖💖 如果命运是世上最烂的编剧。 那么你就要争取，做你人生最好的演员

💖💖💖 写作不易，如果您觉得写的不错，欢迎给博主点赞、收藏、评论来一波~让博主更有动力吧