第十六章《持久化》

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
简介: 第十六章《持久化》

redis 持久化
RDB:快照的形式实现的持久化
AOF:日志的形式实现的持久化

1.RDB:默认的持久化方式,把某一时刻redis内存中的数据以二进制文件的形式保存到磁盘中
触发机制:
【手动】:save、bgsave

             save:阻塞当前的redis服务,将数据dump到零时的dump.rdb这个文件,然后再把dump.rdb文件保存到磁盘中(线上不建议使用,阻塞redis服务)
             bgsave:fork出一个子进程,由子进程完成持久化,只有fork子进程这个过程阻塞;
             在执行debug load重载或者是shutdown关闭redis服务,默认都会执行bgsave;

【自动】:通过配置文件来配置

save 900 1 //900秒内进行一次数据操作更新就会触发
save 300 10 //300秒内进行10次数据更新更新就会触发
save 60 10000 //60秒内进行10000次数据更新就会触发

RDB持久化的优缺点;
优点:
(1)rdb是一个紧凑压缩的二进制文件,代表redis在某一个时间点上的数据快照,非常适用于全量备份的场景。(2)redis加载rdb文件来会数据要快AOF的方式
缺点:
(1)RDB持久化方式没法做到实时持久化/秒级持久化,因为每次bgsave每次都会fork子进程,属于重量级操作,频繁执行会消耗redis性能,阻塞redis服务;
(2)rdb文件使用特定二进制格式保存,redis不同版本兼容的二进制格式不同
(3)如果在save的过程当中redis宕机,没有被持久化到磁盘的这部分数据会丢失,为了解决这个问题,redis提供了AOF持久化方式。

AOF(append only file):以独立日志的方式记录每次写命令,重启时在重新执行AOF日志中记录的写命令,达到恢复数据的目的,AOF就是用来解决数据的实时持久化;
appendonly yes //开启AOF持久化
appendfilename “appendonly.aof” //默认的aof文件名
AOF的同步策略
appendfsync always //redis每写入一条数据就会调用fsync同步到磁盘的aof文件;
appendfsync everysec //每隔一秒钟同步一次
appendfsync no //不进行同步;默认每隔30s进行一次同步

AOFrewrite:随着写入aof文件的内容越来越多,aof文件变得更大
(1)进程中已经超时的数据不在写入文件
(2)旧的aof文件中包含了无效命令,比如del key1、hdel key2 、srem keys、set 111 、set 222、set 333这些命令

【手动】bgrewrite 触发重写aof文件
【自动】
auto-aof-rewrite-percentage 100 //当aof文件里面的内容超过了预设定值的100%
auto-aof-rewrite-min-size 64mb //触发重写的aof文件量不少于64M

aof持久化流程
(1)所有写入命令追加到aof_buf(缓冲区)中;
(2)aof缓冲区根据对应策略向硬盘做同步操作
(3)随着aof文件越来越大,需要定期对aof文件进行重写,达到压缩目的

小知识:
(1)在aof文件没有进行重写之前我们可以通过编辑appendonly.aof文件来取消误操作
(2)redis重启时会优先加载aof文件进行数据恢复,因为aof文件数据比较完整。

持久化常见问题和优化;
1.fork操作:
当redis进行rdb和aof重写时,都必须要fork子进程,对于操作系统来说fork属于一个重量级操作
在fork的过程中会阻塞,特别是我们使用的时虚拟化技术尤其是Xen虚拟机,fork会更耗时
优化;
(1)优先使用物理机或者高效支持fork操作的虚拟化技术;
(2)控制redis实例最大可用内存,fork耗时和内存量成正比,线上建议每隔redis内存控制在10G以内
2.子进程开销和优化:
(1)cpu:子进程负责把进程内的数据分批写入文件,cpu密集操作,子进程对单核cpu利用率接近90%
优化:尽量redis服务多分配cpu核心数,不要和其他cpu密集型应用或服务部署到同一台服务器;
(2)内存:子进程理论上也会占用和父进程一样的内存,所以对内存的消耗也很大
优化:内存存储的数据量不要太大,不要和其他内存使用量大的服务器部署在同一台服务器;
(3)硬盘:子进程主要用于将内存中的数据同步到硬盘中,因此在持久化的过程中对硬盘的I/O性能开销大。aof文件的重写也会消耗大量的硬盘IO;
优化:(1)不要和其他高硬盘负载的服务部署在一起

       (2)对于多个redis实例部署在一台机器上这种情况,我们可以通过设置不同数据保存路径来分摊硬盘的写入压力
       (3)AOF重写消耗大量硬盘IO,可以开启no-appendfsync-on-rewrite yes 标识在重写期间不进行sync操作
       
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
3月前
|
存储 Kubernetes 调度
在K8S中,怎样实现数据持久化?
在K8S中,怎样实现数据持久化?
|
3月前
|
消息中间件 存储 Kafka
【Kafka大揭秘】掌握这些秘籍,让你的消息状态跟踪稳如老狗,再也不怕数据丢失的尴尬时刻!
【8月更文挑战第24天】Kafka作为一个领先的分布式流数据平台,凭借其出色的性能和扩展性广受青睐。为了保障消息的可靠传输与处理,Kafka提供了一系列核心机制:生产者确认确保消息成功到达;消费者位移管理支持消息追踪与恢复;事务性消息保证数据一致性;Kafka Streams的状态存储则适用于复杂的流处理任务。本文将详细解析这些机制并附带示例代码,帮助开发者构建高效稳定的消息处理系统。
43 5
|
3月前
|
算法 Shell
数据魔术师:如何在ClkLog中恢复丢失数据并实现数据更新
​ 在数字化的世界里,数据就是企业的血液,是推动业务发展的关键动力。想象一下,你正在运行你的业务,依赖ClkLog为你提供的数据,突然,由于网络波动或其他原因,定时脚本未能执行,页面上的数据缺失了。或者你刚刚优化了你的算法,但你需要重新计算以前的数据以便与新的算法保持一致。这种情况下,数据的完整性和稳定性就显得尤为重要,它们不仅影响业务的正常运行,而且直接关系到业务决策的准确性和及时性。
数据魔术师:如何在ClkLog中恢复丢失数据并实现数据更新
|
6月前
|
网络协议 算法 开发者
如何实现网络同步?
【5月更文挑战第3天】如何实现网络同步?
130 9
|
6月前
|
存储 JavaScript 搜索推荐
【掰开揉碎】Redux的持久化和非持久化
【掰开揉碎】Redux的持久化和非持久化
124 0
|
6月前
|
关系型数据库 MySQL
Mysql基础第二十九天,管理事务处理
Mysql基础第二十九天,管理事务处理
29 0
Mysql基础第二十九天,管理事务处理
|
存储 Kubernetes NoSQL
【k8s 系列】k8s 学习二十二,持久化存储
我们继续来查看 k8s 的卷,上一次我们分享了将磁盘挂载到容器中,empyDir 和 gitRepo 都是会随着 pod 的启动而创建,随着 pod 的删除而销毁
162 0
|
存储 XML Java
何为消息持久化?
持久化(Persistence),即把数据(如内存中的对象)保存到可永久保存的存储设备中(如磁盘)。持久化的主要应用是将内存中的对象存储在关系型的数据库中,当然也可以存储在磁盘文件中、XML数据文件中等等。
119 0
|
消息中间件 存储 NoSQL
三歪吐血总结了各个中间件是如何实现持久化的
到目前为止,三歪也已经接触到了不少的中间件了,比如说「Elasticsearch」「Redis」「HDFS」「Kafka」「HBase」等等。 可以发现的是,它们的持久化机制都差不得太多。今天想来总结一下,一方面想来回顾一下这些组件,一方面给还没入门过这些中间件的同学总结一下持久化的”套路“,后面再去学习的时候就会轻松很多。
193 9
三歪吐血总结了各个中间件是如何实现持久化的
|
设计模式 存储 缓存
再有人问你数据库缓存一致性的问题,直接把这篇文章发给他
在之前的一篇文章《为什么会出现数据库和缓存不一致的问题》中,我们介绍过缓存和数据库会出现数据不一致的几种情况。 我们提到过,在数据库和缓存的操作过程中,可能存在”先写数据库,后删缓存”、”先写数据库,后更新缓存”、”先删缓存库,后写数据库”以及”先更新缓存库,后写数据库”这四种。 那么,到底是应该删