|大数据必学：redis深入了解 Redis 的持久化机制(RDB、AOF)
文章图片
文章图片
文章图片
文章图片
文章图片
因为 redis是一个内存数据库 ， 所有数据都存储在内存中 ， 而且内存中的数据非常容易丢失 ， 所以 redis的数据持久化就变得非常重要 ， redis提供了两种数据持久化方法 ， 分别用于 RDB和 AOF ， 而 redis默认用于 RDB的数据持久化方法 。
一、RDB持久性方案简介RDB方案简介：
Redis将定期将数据快照保存到 rdb文件中 ， 并在启动时自动装入 rdb文件 ， 以恢复之前保存的数据 。 可将 Redis配置为在配置文件中保存快照 。
save [seconds
[changes
意思是[seconds
秒内如果发生了[changes
次数据修改 ， 则进行一次RDB快照保存 ， 例如：
save 60 100
每隔60秒 Redis就会检查一次数据更改 ， 如果发生了100次或更多的数据更改 ， 将保存 RDB快照 。 多个 save指令可以进行配置 ，Redis可以执行多层快照保存策略 。 默认打开 RDB快照 。 RDB快照保存还可以通过 SAVE或 BGSAVE命令手动触发 。
在 SAVE和 BGSAVE命令中 ，rdbSave函数都被调用 ， 但是它们以不同的方式调用：
1、在保存完成之前 ，SAVE直接调用 rdbSave来阻塞 Redis主进程 。 服务器无法在主进程阻塞期间处理客户机的任何请求 。
2、而 BGSAVE则把子进程 fork出来 ， 该进程负责调用 rdbSave ， 并在保存完成后向主进程发出通知 ， 告知保存完成 。 在 BGSAVE执行过程中 ，Redis服务器仍可继续处理客户机请求 。
RDB方案好处：
1、最低限度的性能影响 。 如前所述 ， 当保存 RDB快照时 ，Redis将对 fork出子进程执行 ， 这几乎不会影响 Redis处理客户机请求的效率 。
2、每一张快照都会产生一个完整的数据快照文件 ， 因此可以用其他方法来同时保存多个时间点的快照(例如将每天0点的快照备份到其他存储介质) ， 作为非常可靠的灾难恢复方法 。
3、与 AOF相比 ， 使用 RDB文件的数据恢复更快
RDB模式缺陷：
1、快照是定期生成的 ， 因此当使用 Redis crash时 ， 数据的一部分或多或少会丢失 。
2、当数据集非常大 ，CPU不够强时(例如单核 CPU) Redis可能会花费相对较长的 fork子进程时间 ， 从而影响 Redis外部服务的提供 。
RDB方案配置：
修改redis的配置文件：
重启 redis Service
每生成一个新的 dump. rdb ， 就覆盖以前的旧快照
二、AOF持久化方案简介1、AOF方案简介：
AOF (append only file)持久化：将每个写入命令以独立日志的方式记录下来 ， 重启后再重新执行 AOF文件中的命令 ， 以实现数据恢复 。 AOF的主要功能是处理数据持久的实时性 ， 目前 ，AOF已成为 Redis持久性的主流方式 。 了解掌握 AOF的持久性机制对于我们处理数据安全和性能方面非常有帮助 。
2、运用AOF：
打开 AOF功能要求进行设置配置： appendonlyyes ， 默认不启用 。 通过 appendfilename配置设置 AOF文件名 ， 默认的文件名是appendonly.ao f 。 通过 dir配置指定 ， 保存路径与 RDB持久化方式一致 。 AOF工作流程操作 ：命令写入(append) ， 文件同步(sync) ， 文件重写(rewrite) ， 重新启动装载(load) ， 如图所示 。
执行流程：
1、所有的写入命令会追加到aof_buf（缓冲区）中 。
2、根据相应的策略 ，AOF缓冲区对硬盘进行同步操作 。
3、当 AOF文件变得更大时 ， 需要定期重写 AOF文件 ， 以实现压缩 。
4、重启 Redis服务器后 ， 可以加载用于数据恢复的 AOF文件 。
3、文件同步：
Redis提供了多种 AOF缓冲同步文件策略 ， 这些策略由 appendfsync参数控制 ， 图中显示了不同值的含义 。
3.1、当配置为 always时 ， 每次写入都会同步 AOF文件 ， 而在普通 SATA硬盘上 ，Redis只支持大约数百 TPS写入 ， 这显然与 Redis的高性能特性背道而驰 ， 因此不推荐使用 。
3.2、配置为no ， 因为操作系统对 AOF文件的每一次同步都是不可控制的周期 ， 并且会增加每一次同步硬盘的数据量 ， 虽然提高了性能 ， 但是数据安全没有保障 。
3.3、配置为everysec ， 建议采用同步策略和默认策略 ， 以兼顾性能和数据安全 。
4、重写机制：
AOF会随着命令的执行而变大 ， 为了解决这个问题 ，Redis引入了 AOF覆盖机制来压缩文件 。 AOF文件覆盖是将 Redis进程中的数据转换成写入命令 ， 使其与新 AOF文件同步的过程 。
为什么覆盖了 AOF的文件可以变小？原因如下：
1、已在进程中超时的数据不再写入文件 。
2、以前的 AOF文件中包含诸如 delkey1 hdelkey2 srem keysseta111 seta222等等无效命令 。 覆盖直接使用进程中的数据生成 ， 因此新的 AOF文件只保存最终数据的写入命令 。
3、可以将多个写命令合并成一个 ， 例如： lpush list a、lpush list b、lpush list c可转换为： lpush list a b c。 为避免单个命令太大导致客户端缓冲区溢出 ， 对于 list set hash zset之类的类型操作 ， 将多个元素分割成64个界限 。
AOF重写减少了文件占用空间 ， 除此之外 ， 还有另外一个目的： Redis可以更快地加载更小的 AOF文件 。
可手动或自动触发 AOF重写过程：
手动触发：直接调用命令 bgrewriteaof 。
自动触发：Auto-aof-rewrite-min-size和Auto-aof-rewrite-percentage参数决定了自动触发的时间点 。
解释：
1、auto-aof-rewrite-min-size：表示在运行 AOF覆盖时 ， 文件的最小体积 ， 默认值为64 MB 。
2、auto-aof-rewrite-percentage：表示 AOF文件空间(aof_current_size)与上次重写后的 AOF文件空间之间的比值 。
3、自动触发时机=aof_current_size>auto-aof-rewrite-min-size&&(aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage
AOF场景配置：
1、在 redis中 ，aof的持久化机制默认关闭
2、AOF持久化默认为关闭的， RDB持久化默认为打开
3、appendonly yes ， 能够打开 AOF持久机制 ， 在生产环境中 ， 通常 AOF都会被打开 ， 除非你不介意数据被随意丢失几分钟
4、在打开 AOF持久化机制后 ，redis每次收到写命令时 ， 都会将其写入日志文件 ， 当然是先写入 os cache ， 然后每隔一段时间再进行 fsync
5、当 AOF和 RDB都打开并且 redis重新启动时 ， 优先使用 AOF恢复数据 ， 因为 aof数据比较完整
AOF的 fsync策略可以进行配置 ， 有三种策略可供选择：
1、一种是每次写入数据时都执行一次 fsync 。
2、另一种是每隔一秒执行一次 fsync 。
3、另一种是不主动执行 fsync 。
always：每写一次 ， 就把相应于该数据的写日志 fsync放到磁盘上 ， 性能非常糟糕 ， 吞吐量也很低；要确保说 redis中的一个数据不会丢失 ， 只能这样 。
redis中的默认 AOF持久性机制全部关闭
Redis的AOF持久化机制配置：
重新启动 redis实例 ， 并在执行简单操作后关闭该实例 ， 重新启动 redis实例 。
三、重启加载流程：
如果觉得对你有所帮助 。 记得收藏和关注呦！（每日更新各种大数据框架）
如需转载请注明出处（创作不易请见谅）
和巨婴程序猿一起成长 。 让自己变得更优秀
想了解更多精彩内容 ， 快来关注跟着巨婴去逆袭
我最近一直在思考（大数据通俗讲解）的问题 ， 你的看法是什么呢？关注我快说出来一起交流一下吧~
【|大数据必学：redis深入了解 Redis 的持久化机制(RDB、AOF)】
推荐阅读
- 凉茶|凉茶最大的问题不是添加西药，而是冒充饮料
- 上汽大众途观x|颜值比途观L高！上汽大众途观X将亮相2020北京车展，明年初上市
- 未来的大学生活“长啥样”？ 来看学长为你写下的万字指南
- the|新冠肺炎成美国第三大致死原因 仅次于心脏病和癌症
- 多所在京大学录取线来了 各校设置多条投档线
- 旅行路上阿|成都反差最大景区，一边是游客专属一边本地人最爱，门票相差4倍
- 旅行在路上啊|成都反差最大景区，一边是游客专属一边本地人最爱，门票相差4倍
- 腾讯任天堂Switch国行《健身环大冒险》将于8月19日发布
- 珠海生活资讯交流|推动琴澳旅游合作, 大横琴文旅展示中心18日在横琴口岸正式开放
- 提供“让兴趣成为职业”的可能 “微经济”有大宝藏