Redis之分布式缓存使用解读
更新时间：2026年03月20日 10:45:37 作者：java_Almighty
这篇文章主要介绍了Redis之分布式缓存使用,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
单节点Redis问题：
- 数据丢失：实现Redis数据持久化，保存在磁盘
- 存储能力：搭建分片集群，利用插槽机制实现动态扩容
- 并发能力：搭建主从集群，实现读写分离
- 故障回复：利用Redis哨兵，实现检测和自动恢复
Redis持久化
RDB持久化
Redis数据备份文件，也被叫做Redis数据快照，就是把内存中所有数据都记录到磁盘，当Redis实例故障重启后，从磁盘读取快照文件恢复数据
——主动宕机会自动执行一次RDB
save //由Redis主进程执行RDB，会阻塞所有命令 bgsave //开启子进程执行RDB，避免主进程受到影响
Redis内部有触发RDB的机制，可以在redis.conf文件找到：
Redis配置文件中的RDB持久化规则 save 900 1 # 900秒（15分钟）内，如果至少有1个key被修改，则执行bgsave save 300 10 # 300秒（5分钟）内，如果至少有10个key被修改，则执行bgsave save 60 10000 # 60秒（1分钟）内，如果至少有10000个key被修改，则执行bgsave 禁用RDB持久化（生产环境慎用） save ""
RDB的其他配置也可以在redis.conf文件设置：
# RDB持久化压缩配置（默认开启，建议不开启，压缩会消耗CPU，磁盘不值钱） rdbcompression yes # 是否压缩RDB文件，yes开启压缩，no关闭压缩 # RDB文件名称配置 dbfilename dump.rdb # RDB文件的名称 # RDB文件保存目录配置 dir ./ # RDB文件保存的目录路径
bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据，完成fork读取内存数据并写入RDB文件
fork采用copy-on-write技术：
- 当主进程执行读操作时，访问共享内存
- 当主进程执行写操作时，则会拷贝一份数据看，执行写操作
RDB总结
RDB方式bgsave基本流程：
- → fork主进程得到一个子进程，共享内存空间
- → 子进程读取内存数据并写入新的RDB文件
- → 用新的RDB文件替代旧的RDB文件
RDB执行时机：
默认是服务停止时
RDB的缺点：
- RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
- fork子进程、压缩、写入RDB文件比较耗时
AOF持久化
因为是记录命令，AOF文件比RDB文件大，而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义
——执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少命令达到相同效果
AOF默认关闭，需要修改redis.conf配置文件来开启AOF
# AOF持久化开关 appendonly yes # 是否开启AOF功能，默认是no # AOF文件名称 appendfilename "appendonly.aof" # AOF文件的名称
AOF的命令记录的频率也可以通过redis.conf文件配置
//表示每执行一次写命令，立即记录到AOF文件 appendfsync always //写命令执行完先放入AOF缓冲区，然后每个1秒将缓冲区数据写到AOF文件（默认）3 appendfsync everysec //写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
| 策略 | 配置值 | 同步时机 | 数据安全 | 性能影响 | 适用场景 |
|---|---|---|---|---|---|
| always | appendfsync always | 每次写命令后立即同步 | 最高（零丢失） | 最低（性能差） | 金融交易、支付系统 |
| everysec | appendfsync everysec | 每秒同步一次（默认） | 较高（最多丢失1秒） | 中等（推荐） | 大多数生产环境 |
| no | appendfsync no | 由操作系统决定（通常30秒） | 最低（可能丢失>30秒） | 最高（性能最好） | 缓存、非关键数据 |
Redis会在触发阈值时自动去重写AOF文件，阈值可在redis.conf中配置
//AOF文件比上次文件增长超过多少百分比则触发重写 auto-aof-rerite-percentage 100 //AOF文件体积最小多大以上才触发重写 auto-aof-rerite-min-size 64mb
AOF和RDB对比
AOF和RDB各有优缺点，如果对数据安全性要求高，在实际开发中会结合两者使用
| 对比维度 | RDB | AOF |
|---|---|---|
| 持久化方式 | 定时对整个内存做快照 | 记录每一次执行的命令 |
| 数据完整性 | 不完整，两次备份之间会丢失 | 相对完整，取决于刷盘策略 |
| 文件大小 | 会有压缩，文件体积小 | 记录命令，文件体积很大 |
| 宕机恢复速度 | 很快 | 慢 |
| 数据恢复优先级 | 低，因为数据完整性不如AOF | 高，因为数据完整性更高 |
| 系统资源占用 | 高，大量CPU和内存消耗（fork子进程） | 低，主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源 |
| 使用场景 | 可以容忍数分钟的数据丢失，追求更快的启动速度 | 对数据安全性要求较高常见 |
Redis主从
单节点Redis的并发能力有上限，要进一步提高Redis的并发能力需要搭建主从集群，实现读写分离.
搭建方式存储于文件Redis集群.md下
数据同步原理
通过master判断slave是不是第一次来同步数据需要掌握两个重要概念：
- Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
- offset ：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新
- 因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据
一、主从第一次同步是全量同步：
结合两个重要概念后：
全量同步流程：
- slave节点请求增量同步
- master节点判断replid，发现不一致，拒绝增量同步
- master将完整内存数据生成RDB，发送RDB到slave
- slave清空本地数据，加载master的RDB
- master将RDB期间的命令记录在repl_baklog,并持续将log中的命令发给slave
- slave执行接收到的命令，保持于master之间的同步
二、主从第一次同步是全量同步，但如果slave重启后同步则执行增量同步
注意：repl_baklog大小上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，只能再次全量同步
优化Redis主从集群方案：
- 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步的磁盘IO
- Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
- 适当提高repl_baklog的大小，发现slave宕机尽快实现故障恢复，尽可能避免全量同步
- 限制一个master上的slave节点数量，如果实在过多slave则采用主-从-从链式结构，减少master压力
Redis主从总结
全量同步和主从同步的区别：
- 全量同步：master将完整内存数据生成RDB，发送到slave。后续命令则记录在repl_baklog，逐个发送给slave
- 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令交给slave
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。
相关文章
本文主要是学习一下redis lua脚本的编写，以及在redisson这个redis客户端中是怎样使用的，实战一下秒杀场景redis减库存lua脚本的编写，并伪真实环境压测查看效果。感兴趣的可以了解一下2021-11-11
这篇文章主要介绍了Redis+Caffeine实现分布式二级缓存组件实战教程,介绍了分布式二级缓存的优势，使用组件的方法，通过示例代码给大家介绍的非常详细，需要的朋友可以参考下2022-08-08
在Redis中,红锁是一种分布式锁的实现机制,旨在解决多个客户端在分布式环境中对共享资源进行并发访问的问题,本文主要介绍了Redis分布式锁之红锁的实现,具有一定的参考价值,感兴趣的可以了解一下2023-12-12
内存碎片是redis服务中分配器分配存储对象内存的时产生的,下面这篇文章主要给大家介绍了关于Redis内存碎片处理的相关资料,文中通过实例代码介绍的非常详细,需要的朋友可以参考下2022-05-05
这篇文章主要给大家介绍了关于Redis中LFU算法的相关资料，文中通过示例代码介绍的非常详细，对大家学习或者使用Redis具有一定的参考学习价值，需要的朋友们下面来一起学习学习吧2019-06-06
发布订阅在应用级其作用是为了减少依赖关系，通常也叫观察者模式。主要是把耦合点单独抽离出来作为第三方，隔离易变化的发送方和接收方。下面这篇文章主要给大家介绍了关于Redis发布订阅和实现.NET客户端的相关资料,需要的朋友可以参考下2017-03-03
接口防刷有很多种实现思路，例如：拦截器/AOP+Redis、拦截器/AOP+本地缓存、前端限制等等很多种实现思路，本文主要来讲一下 拦截器+Redis 的实现方式，需要的可以参考下2023-08-08
本文介绍了使用Redis实现分布式锁的续期,包括使用Lua脚本、Redlock算法和Redisson客户端等方法,具有一定的参考价值,感兴趣的可以了解一下2024-12-12
在自然语言处理领域，有一个常见且重要的任务就是文本相似度搜索，所以本文为大家介绍一下如何利用Redis实现向量相似度搜索，解决文本、图像和音频之间的相似度匹配问题，需要的可以了解下2023-07-07
在 Redis 中,键的过期时间设计与实现是一个重要的功能,这使得 Redis 可以自动删除在指定时间后不再需要的键,下面详细介绍 Redis 过期时间的设计和实现,包括设置过期时间、过期键的存储结构、过期键的删除策略等,需要的朋友可以参考下2024-08-08
最新评论