高并发核心技术Redis系列(五)--------持久化和事务(上)

简介: 由于Redis的数据都存放在内存中,如果没有配置持久化,Redis重启后数据就全丢失了,于是需要开启Redis的持久化功能,将数据保存到磁盘上,当Redis重启后,可以从磁盘中恢复数据。

一、Redis持久化

     由于Redis的数据都存放在内存中,如果没有配置持久化,Redis重启后数据就全丢失了,于是需要开启Redis的持久化功能,将数据保存到磁盘上,当Redis重启后,可以从磁盘中恢复数据。

Redis提供了两个不同形式的持久化方式:

  • RDB(Redis DataBase)
  • AOF(Append Only File)

1 持久化操作-RDB

1.1 RDB是什么?

在指定的时间间隔内将内存的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。

1.2 备份过程

Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

2345_image_file_copy_141.jpg

1.3 dump.rdb文件

1. RDB保存的文件,在redis.conf中配置文件名称,默认为dump.rdb。

2345_image_file_copy_142.jpg

2. rdb文件的保存位置,也可以修改。默认在Redis启动时命令行所在的目录下。

2345_image_file_copy_143.jpg

redis.conf中配置文件路径

2345_image_file_copy_144.jpg

1.4 如何触发快照?

      1.4.1 配置文件中默认的快照配置

2345_image_file_copy_145.jpg

1. 快照默认配置

save 3600 1:表示3600秒内(一小时)如果至少有1个key的值变化,则保存
save 300 100:表示300秒内(五分钟)如果至少有100个 key 的值变化,则保存
save 60 10000:表示60秒内如果至少有 10000个key的值变化,则保存

可以自己配置新的保存规则。

2. 例:给redis.conf添加新的快照策略,30秒内如果有5次key的变化,则触发快照。配置修改后,需要重启Redis服务。

2345_image_file_copy_146.jpg

dump.rdb默认大小是92字节,里面会有一些基本信息。

2345_image_file_copy_147.jpg

30秒内设置5个以上的值。

set k1 v1
set k2 v2
set k3 v3
set k4 v4
set k5 v5
set k6 v6
set k7 v7

2345_image_file_copy_148.jpg

dump.rdb大小已经改变。

2345_image_file_copy_149.jpg

1.4.2 flushall

执行flushall命令,也会触发rdb规则。

1.4.3 save与bgsave

手动触发Redis进行RDB持久化的命令有两种:

1. save

该命令会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB过程完成为止,不建议使用。

2. bgsave

执行该命令时,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。

这两个命令是在Redis客户端中执行,并不是redis.conf中修改。

1.4.4 stop-writes-on-bgsave-error

默认值是yes。当Redis无法写入磁盘的话,直接关闭Redis的写操作。

2345_image_file_copy_150.jpg

1.4.5 rdbcompression

默认值是yes。对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能,但是存储在磁盘上的快照会比较大。

2345_image_file_copy_151.jpg

1.4.6 rdbchecksum

默认值是yes。在存储快照后,我们还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能。

2345_image_file_copy_152.jpg

1.5 恢复数据

   只需要将rdb文件放在Redis的启动目录,Redis启动时会自动加载dump.rdb并恢复数据。

2 持久化操作-AOF

2.1 AOF是什么?

以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只允许加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2.2 AOF持久化流程

1. 客户端的请求写命令会被append追加到AOF缓冲区内。

2. AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作同步到磁盘的AOF文件中。

3. AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量。

4. Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的。


2345_image_file_copy_153.jpg

2.3 AOF默认不开启

可以在redis.conf中配置文件名称,默认为appendonly.aof。

AOF文件的保存路径,同RDB的路径一致。

2345_image_file_copy_154.jpg

如果AOF和RDB同时启动,Redis默认读取AOF的数据。

2.4 AOF启动/修复/恢复

正常恢复

1. 启动:设置Yes:修改默认的appendonly no,改为yes。

2. 恢复:重启Redis然后重新加载。

例:设置appendonly为yes,配置修改后,需要重启Redis服务。

2345_image_file_copy_155.jpg

服务器启动后,生成appendonly.aof文件,且大小为0。

2345_image_file_copy_156.jpg

设置数据。

set k11 v11
set k12 v12
set k13 v13
set k14 v14
set k15 v15

appendonly.aof大小已经改变。

2345_image_file_copy_157.jpg 

异常恢复

1. 启动:设置Yes:修改默认的appendonly no,改为yes。

2. 修复:如遇到AOF文件损坏,通过/user/local/bin/redis-check-aof --fix appendonly.aof进行恢复。

3. 恢复:重启Redis然后重新加载。

例:服务启动和数据设置同上,模拟损坏appendonly.aof文件

vi appendonly.aof

重启Redis服务,并连接。由于aof文件被破坏,导致服务器启动失败。

2345_image_file_copy_158.jpg

通过/user/local/bin/redis-check-aof --fix工具对appendonly.aof进行恢复。

./redis-check-aof --fix appendonly.aof

2345_image_file_copy_159.jpg

修复成功。再次查看aof文件,破坏的地方已经修复。再次启动服务器成功。

2345_image_file_copy_160.jpg


目录
相关文章
|
6月前
|
监控 NoSQL 关系型数据库
Redis:事务(Transactions)
Redis事务支持将多个命令打包执行,但与MySQL不同,它不保证原子性、一致性、持久性和隔离性。Redis事务的核心在于“打包”命令,避免其他客户端插队,通过MULTI、EXEC、DISCARD等命令实现。此外,Redis提供WATCH和UNWATCH机制,用于监控键变化,实现类似“乐观锁”的功能,提升并发操作的安全性。
|
8月前
|
缓存 关系型数据库 MySQL
在MySQL中处理高并发和负载峰值的关键技术与策略
采用上述策略和技术时,每个环节都要进行细致的规划和测试,确保数据库系统既能满足高并发的要求,又要保持足够的灵活性来应对各种突发的流量峰值。实施时,合理评估和测试改动对系统性能的影响,避免单一措施可能引起的连锁反应。持续的系统监控和分析将对维护系统稳定性和进行未来规划提供重要信息。
379 15
|
9月前
|
缓存 NoSQL 算法
高并发秒杀系统实战(Redis+Lua分布式锁防超卖与库存扣减优化)
秒杀系统面临瞬时高并发、资源竞争和数据一致性挑战。传统方案如数据库锁或应用层锁存在性能瓶颈或分布式问题,而基于Redis的分布式锁与Lua脚本原子操作成为高效解决方案。通过Redis的`SETNX`实现分布式锁,结合Lua脚本完成库存扣减,确保操作原子性并大幅提升性能(QPS从120提升至8,200)。此外,分段库存策略、多级限流及服务降级机制进一步优化系统稳定性。最佳实践包括分层防控、黄金扣减法则与容灾设计,强调根据业务特性灵活组合技术手段以应对高并发场景。
2415 7
|
8月前
|
缓存 NoSQL Java
Java 项目实操高并发电商系统核心模块实现从基础到进阶的长尾技术要点详解 Java 项目实操
本项目实战实现高并发电商系统核心模块,涵盖商品、订单与库存服务。采用Spring Boot 3、Redis 7、RabbitMQ等最新技术栈,通过秒杀场景解决库存超卖、限流熔断及分布式事务难题。结合多级缓存优化查询性能,提升系统稳定性与吞吐能力,适用于Java微服务开发进阶学习。
311 0
|
10月前
|
NoSQL 算法 安全
redis分布式锁在高并发场景下的方案设计与性能提升
本文探讨了Redis分布式锁在主从架构下失效的问题及其解决方案。首先通过CAP理论分析,Redis遵循AP原则,导致锁可能失效。针对此问题,提出两种解决方案:Zookeeper分布式锁(追求CP一致性)和Redlock算法(基于多个Redis实例提升可靠性)。文章还讨论了可能遇到的“坑”,如加从节点引发超卖问题、建议Redis节点数为奇数以及持久化策略对锁的影响。最后,从性能优化角度出发,介绍了减少锁粒度和分段锁的策略,并结合实际场景(如下单重复提交、支付与取消订单冲突)展示了分布式锁的应用方法。
753 3
|
缓存 NoSQL 架构师
Redis批量查询的四种技巧,应对高并发场景的利器!
在高并发场景下,巧妙地利用缓存批量查询技巧能够显著提高系统性能。 在笔者看来,熟练掌握细粒度的缓存使用是每位架构师必备的技能。因此,在本文中,我们将深入探讨 Redis 中批量查询的一些技巧,希望能够给你带来一些启发。
Redis批量查询的四种技巧,应对高并发场景的利器!
|
11月前
|
人工智能 缓存 NoSQL
高并发秒杀系统设计:关键技术解析与典型陷阱规避
在电商、在线票务等场景中,高并发秒杀活动对系统性能和稳定性提出极大挑战。海量请求可能导致服务器资源耗尽、数据库锁争用及库存超卖等问题。通过飞算JavaAI生成的Redis + Lua分布式锁代码,可有效解决高并发下的锁问题,提升系统QPS达70%,同时避免缓存击穿与库存超卖。相较传统写法,AI优化代码显著提高性能与响应速度,为高并发系统开发提供高效解决方案。
|
存储 缓存 监控
社交软件红包技术解密(四):微信红包系统是如何应对高并发的
本文将为读者介绍微信百亿级别红包背后的高并发设计实践,内容包括微信红包系统的技术难点、解决高并发问题通常使用的方案,以及微信红包系统的所采用高并发解决方案。
399 13
|
存储 缓存 NoSQL
云端问道21期方案教学-应对高并发,利用云数据库 Tair(兼容 Redis®*)缓存实现极速响应
云端问道21期方案教学-应对高并发,利用云数据库 Tair(兼容 Redis®*)缓存实现极速响应
385 1
|
缓存 NoSQL 关系型数据库
云端问道21期实操教学-应对高并发,利用云数据库 Tair(兼容 Redis®)缓存实现极速响应
本文介绍了如何通过云端问道21期实操教学,利用云数据库 Tair(兼容 Redis®)缓存实现高并发场景下的极速响应。主要内容分为四部分:方案概览、部署准备、一键部署和完成及清理。方案概览中,展示了如何使用 Redis 提升业务性能,降低响应时间;部署准备介绍了账号注册与充值步骤;一键部署详细讲解了创建 ECS、RDS 和 Redis 实例的过程;最后,通过对比测试验证了 Redis 缓存的有效性,并指导用户清理资源以避免额外费用。
304 1