刨根问底redis三-Redis的持久化机制

2、set值

​​

3、执行shutdown命令关掉服务，查看目录，已经生成对应的dump文件。

4、重启redis服务，发现数据还存在

5、执行shutdown命令关掉服务，并把dump文件删除

6、启动redis在进行查看，发现存储的数据已经不存在了。

2.4 RDB持久化的优缺点

优点：

• 压缩后的二进制文，适用于备份、全量复制，用于灾难恢复

• 加载RDB恢复数据远快于AOF方式

缺点：

• 无法做到实时持久化，每次都要创建子进程，频繁操作成本过高

三、AOF持久化

===============================================================================

针对RDB不适合实时持久化，redis提供了AOF持久化方式来解决

开启方式就是在redis.conf设置：appendonly yes  (默认不开启，为no)

默认文件名：appendfilename “appendonly.aof”

3.1 AOF持久化原理

1. 所有的写入命令(set hset)会append追加到aof_buf缓冲区中

2. AOF缓冲区向硬盘做sync同步

3. 随着AOF文件越来越大，需定期对AOF文件rewrite重写，达到压缩

4. 当redis服务重启，可load加载AOF文件进行恢复

3.2 AOF持久化配置

| | |

| — | — |

| 配置信息 | 含义 |

| appendonly yes | 启用aof持久化方式 |

| appendfsync always | 每收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用 |

| appendfsync everysec | 每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐 |

| no-appendfsync-on-rewrite  yes | 正在导出rdb快照的过程中,要不要停止同步aof |

| auto-aof-rewrite-percentage 100 | aof文件大小比起上次重写时的大小,增长率100%时,重写 |

| auto-aof-rewrite-min-size 64mb | aof文件,至少超过64M时,重写 |

3.3 AOF持久化恢复

1. 设置appendonly yes；

2. 将appendonly.aof放到dir参数指定的目录；

3. 启动Redis，Redis会自动加载appendonly.aof文件。

四、Redis持久化加载机制顺序

===================================================================================

结语

小编也是很有感触，如果一直都是在中小公司，没有接触过大型的互联网架构设计的话，只靠自己看书去提升可能一辈子都很难达到高级架构师的技术和认知高度。向厉害的人去学习是最有效减少时间摸索、精力浪费的方式。

我们选择的这个行业就一直要持续的学习，又很吃青春饭。

虽然大家可能经常见到说程序员年薪几十万，但这样的人毕竟不是大部份，要么是有名校光环，要么是在阿里华为这样的大企业。年龄一大，更有可能被裁。

送给每一位想学习Java小伙伴，用来提升自己。

本文到这里就结束了，喜欢的朋友可以帮忙点赞和评论一下，感谢支持！
到说程序员年薪几十万，但这样的人毕竟不是大部份，要么是有名校光环，要么是在阿里华为这样的大企业。年龄一大，更有可能被裁。

送给每一位想学习Java小伙伴，用来提升自己。

[外链图片转存中…(img-r6JVdNzm-1719189853734)]

本文到这里就结束了，喜欢的朋友可以帮忙点赞和评论一下，感谢支持！