Redis实战(11)高级特性(3)持久化

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
日志服务 SLS,月写入数据量 50GB 1个月
简介:

redis 是一个支持持久化的内存数据库,也就是说redis 需要经常将内存中的数据同步到磁盘
来保证持久化。redis 支持两种持久化方式,一种是Snapshotting(快照)也是默认方式,另
一种是Append-only file(缩写aof)的方式。下面分别介绍:

一、snapshotting 方式

快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,
默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。

我们可以配置redis在n 秒内如果超过m 个key 被修改就自动做快照,

下面是默认的快照保存配置

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

下面介绍详细的快照保存过程:
1、redis 调用fork,现在有了子进程和父进程。
2.、父进程继续处理client 请求,子进程负责将内存内容写入到临时文件。由于os 的实时复
制机制(copy on write)父子进程会共享相同的物理页面,当父进程处理写请求时os 会为父
进程要修改的页面创建副本,而不是写共享的页面。所以子进程地址空间内的数据是fork

时刻整个数据库的一个快照。

3、当子进程将快照写入临时文件完毕后,用临时文件替换原来的快照文件,然后子进程退出。
client 也可以使用save 或者bgsave 命令通知redis 做一次快照持久化。save 操作是在主线程
中保存快照的,由于redis 是用一个主线程来处理所有client 的请求,这种方式会阻塞所有
client 请求。所以不推荐使用。另一点需要注意的是,每次快照持久化都是将内存数据完整
写入到磁盘一次,并不是增量的只同步变更数据。如果数据量大的话,而且写操作比较多,
必然会引起大量的磁盘io 操作,可能会严重影响性能。

下面将演示各种场景的数据库持久化情况

首先在redis.conf配置文件中配置log日志

204253940.png

然后我们进行如下操作:

203032247.png

查看日志文件

204220110.png

 从日志可以看出,数据库做了一个存盘的操作,将内存的数据写入磁盘了。正常的话,磁盘
上会产生一个dump 文件,用于保存数据库快照,我们来验证一下:

 204354129.png

 硬盘上已经产生了一个数据库快照了。这时侯我们再将redis 启动,看键值还是否真的持久
化到硬盘了。

204449573.png

 

二、aof方式

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

下面介绍Append-only file:
aof 比快照方式有更好的持久化性,是由于在使用aof 持久化方式时,redis 会将每一个收到
的写命令都通过write 函数追加到文件中(默认是appendonly.aof)。当redis 重启时会通过重
新执行文件中保存的写命令来在内存中重建整个数据库的内容。

当然由于os 会在内核中缓存 write 做的修改,所以可能不是立即写到磁盘上。这样aof 方式的持久化也还是有可能会丢失部分修改。

不过我们可以通过配置文件告诉redis 我们想要通过fsync 函数强制os 写入
到磁盘的时机。有三种方式如下(默认是:每秒fsync 一次)

1
2
3
4
appendonly  yes  #启用aof 持久化方式
appendfsync always  #收到写命令就立即写入磁盘,最慢,但是保证完全的持久化
appendfsync everysec  #每秒钟写入磁盘一次,在性能和持久化方面做了很好的折中
appendfsync no  #完全依赖os,性能最好,持久化没保证

接下来我们以实例说明用法:

修改配置文件:

205352695.png

进行一下操作:

205201138.png

我们先设置2 个键值对,然后我们看一下系统中有没有产生appendonly.aof 文件

205455156.png

结果证明产生了,接着我们将redis 再次启动后来看一下数据是否还在

205537863.png

数据还存在系统中,说明系统是在启动时执行了一下从磁盘到内存的load 数据的过程。

aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test
命令100 次,文件中必须保存全部的100 条命令,其实有99 条都是多余的。因为要恢复数
据库的状态其实文件中保存一条set test 100 就够了。为了压缩aof 的持久化文件。redis 提
供了bgrewriteaof 命令。收到此命令redis 将使用与快照类似的方式将内存中的数据以命令
的方式保存到临时文件中,最后替换原来的文件。具体过程如下
1、redis 调用fork ,现在有父子两个进程
2、子进程根据内存中的数据库快照,往临时文件中写入重建数据库状态的命令

3、父进程继续处理client 请求,除了把写命令写入到原来的aof 文件中。同时把收到的写命
令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
4、当子进程把快照内容写入已命令方式写到临时文件中后,子进程发信号通知父进程。然
后父进程把缓存的写命令也写入到临时文件。
5、现在父进程可以使用临时文件替换老的aof 文件,并重命名,后面收到的写命令也开始
往新的aof 文件中追加。
需要注意到是重写aof 文件的操作,并没有读取旧的aof 文件,而是将整个内存中的数据库
内容用命令的方式重写了一个新的aof 文件,这点和快照有点类似。接来我们看一下实际的例
子:
我们先调用5 次incr age 命令:

210429407.png

接下来我们看一下日志文件的大小

210537573.png

大小为533 个字节,接下来我们调用一下bgrewriteaof 命令将内存中的数据重新刷到磁盘的
日志文件中

210706678.png

再看一下磁盘上的日志文件大小

210751278.png

日志文件大小变为84 个字节了,说明原来日志中的重复记录已被刷新掉了。



















本文转自shayang8851CTO博客,原文链接:http://blog.51cto.com/janephp/1340039,如需转载请自行联系原作者

相关文章
|
3月前
|
NoSQL 安全 关系型数据库
Redis:持久化的两种方式
Redis持久化机制主要包括RDB和AOF两种方式。RDB通过生成数据快照进行持久化,支持手动或自动触发,具有加载速度快、文件紧凑等特点,但无法实时保存数据。AOF则记录每个操作命令,保障数据更安全,支持多种写入策略,并可通过重写机制优化文件大小。两者各有优劣,常结合使用以兼顾性能与数据安全。
|
7月前
|
存储 缓存 监控
Redis设计与实现——Redis命令参考与高级特性
Redis 是一个高性能的键值存储系统,支持丰富的数据类型(字符串、列表、哈希、集合等)和多种高级功能。本文档涵盖 Redis 的核心命令分类,包括数据类型操作、事务与脚本、持久化、集群管理、系统监控等。特别介绍了事务的原子性特性、Lua 脚本的执行方式及优势、排序机制、发布订阅模型以及慢查询日志和监视器工具的使用方法。适用于开发者快速掌握 Redis 常用命令及其应用场景,优化系统性能与可靠性。
|
3月前
|
存储 NoSQL 前端开发
Redis专题-实战篇一-基于Session和Redis实现登录业务
本项目基于SpringBoot实现黑马点评系统,涵盖Session与Redis两种登录方案。通过验证码登录、用户信息存储、拦截器校验等流程,解决集群环境下Session不共享问题,采用Redis替代Session实现数据共享与自动续期,提升系统可扩展性与安全性。
246 3
Redis专题-实战篇一-基于Session和Redis实现登录业务
|
3月前
|
存储 缓存 NoSQL
Redis专题-实战篇二-商户查询缓存
本文介绍了缓存的基本概念、应用场景及实现方式,涵盖Redis缓存设计、缓存更新策略、缓存穿透问题及其解决方案。重点讲解了缓存空对象与布隆过滤器的使用,并通过代码示例演示了商铺查询的缓存优化实践。
198 1
Redis专题-实战篇二-商户查询缓存
|
3月前
|
存储 缓存 NoSQL
Redis持久化深度解析:数据安全与性能的平衡艺术
Redis持久化解决内存数据易失问题,提供RDB快照与AOF日志两种机制。RDB恢复快、性能高,但可能丢数据;AOF安全性高,最多丢1秒数据,支持多种写回策略,适合不同场景。Redis 4.0+支持混合持久化,兼顾速度与安全。根据业务需求选择合适方案,实现数据可靠与性能平衡。(238字)
|
9月前
|
数据采集 存储 数据可视化
分布式爬虫框架Scrapy-Redis实战指南
本文介绍如何使用Scrapy-Redis构建分布式爬虫系统,采集携程平台上热门城市的酒店价格与评价信息。通过代理IP、Cookie和User-Agent设置规避反爬策略,实现高效数据抓取。结合价格动态趋势分析,助力酒店业优化市场策略、提升服务质量。技术架构涵盖Scrapy-Redis核心调度、代理中间件及数据解析存储,提供完整的技术路线图与代码示例。
896 0
分布式爬虫框架Scrapy-Redis实战指南
|
6月前
|
缓存 监控 NoSQL
Redis 实操要点:Java 最新技术栈的实战解析
本文介绍了基于Spring Boot 3、Redis 7和Lettuce客户端的Redis高级应用实践。内容包括:1)现代Java项目集成Redis的配置方法;2)使用Redisson实现分布式可重入锁与公平锁;3)缓存模式解决方案,包括布隆过滤器防穿透和随机过期时间防雪崩;4)Redis数据结构的高级应用,如HyperLogLog统计UV和GeoHash处理地理位置。文章提供了详细的代码示例,涵盖Redis在分布式系统中的核心应用场景,特别适合需要处理高并发、分布式锁等问题的开发场景。
411 41
|
6月前
|
存储 监控 NoSQL
流量洪峰应对术:Redis持久化策略与内存压测避坑指南
本文深入解析Redis持久化策略与内存优化技巧,涵盖RDB快照机制、AOF重写原理及混合持久化实践。通过实测数据揭示bgsave内存翻倍风险、Hash结构内存节省方案,并提供高并发场景下的主从复制冲突解决策略。结合压测工具链构建与故障恢复演练,总结出生产环境最佳实践清单。
192 9
|
6月前
|
缓存 NoSQL 算法
高并发秒杀系统实战(Redis+Lua分布式锁防超卖与库存扣减优化)
秒杀系统面临瞬时高并发、资源竞争和数据一致性挑战。传统方案如数据库锁或应用层锁存在性能瓶颈或分布式问题,而基于Redis的分布式锁与Lua脚本原子操作成为高效解决方案。通过Redis的`SETNX`实现分布式锁,结合Lua脚本完成库存扣减,确保操作原子性并大幅提升性能(QPS从120提升至8,200)。此外,分段库存策略、多级限流及服务降级机制进一步优化系统稳定性。最佳实践包括分层防控、黄金扣减法则与容灾设计,强调根据业务特性灵活组合技术手段以应对高并发场景。
1623 7
|
6月前
|
机器学习/深度学习 存储 NoSQL
基于 Flink + Redis 的实时特征工程实战:电商场景动态分桶计数实现
本文介绍了基于 Flink 与 Redis 构建的电商场景下实时特征工程解决方案,重点实现动态分桶计数等复杂特征计算。通过流处理引擎 Flink 实时加工用户行为数据,结合 Redis 高性能存储,满足推荐系统毫秒级特征更新需求。技术架构涵盖状态管理、窗口计算、Redis 数据模型设计及特征服务集成,有效提升模型预测效果与系统吞吐能力。
604 2