redis的缓存策略以及区别（redis缓存的使用逻辑）
mhr18 2025-03-19 00:10 15 浏览 0 评论
一、核心策略对比表
策略名称 | 淘汰逻辑 | 优点 | 缺点 | 适用场景 |
LRU | 淘汰最久未访问的数据 | 实现简单，适应热点数据 | 可能误删近期访问但低频数据 | 常规业务（默认推荐） |
LFU | 淘汰访问频率最低的数据（时间 + 次数） | 精准区分冷热数据 | 实现复杂，内存占用略高 | 数据访问频率差异大的场景 |
FIFO | 淘汰最早写入的数据 | 实现简单，保证时效性 | 无法应对突发访问 | 日志、短期会话等时效性要求高 |
随机淘汰 | 随机删除数据 | 无计算开销 | 命中率不稳定 | 测试环境或数据分布均匀场景 |
仅淘汰过期键 | 仅处理已过期数据 | 避免误删关键数据 | 需依赖合 |
二、策略细节解析
1.LRU（Least Recently Used）
- 实现：Redis 使用 近似 LRU（随机采样 + 淘汰），通过配置 maxmemory-samples 控制采样数量（默认 5）。
- 示例：用户行为记录、商品详情页缓存。
- 优化：结合 volatile-ttl 优先淘汰即将过期的键。
2.LFU（Least Frequently Used）
- 实现：维护访问次数（计数器）和时间衰减，Redis 2.8+ 支持。
- 参数：lfu-log-factor：控制频率计数的衰减速度（默认 10）。lfu-decay-time：时间衰减单位（分钟，默认 1）。
- 适用：用户高频访问但偶尔冷启动的场景（如电商热门商品）。
3.FIFO
- 替代方案：使用 List 结构存储数据，手动维护顺序。通过脚本定期删除最旧的键。
- 局限：无法利用 Redis 原生淘汰机制，需额外开发。
4.仅淘汰过期键
- 子策略：volatile-ttl：优先淘汰剩余存活时间最短的键。volatile-lru/volatile-lfu：在过期键中应用 LRU/LFU。
- 建议：对需要长期保留的键不设置过期时间，避免被淘汰。
三、选择策略的 3 个维度
- 数据特征：冷热分明 → LRU/LFU。时效性强 → FIFO 或 volatile-ttl。均匀分布 → 随机淘汰。
- 业务优先级：不允许丢失 → 仅淘汰过期键 + 持久化。可接受部分丢失 → LRU/LFU。
- 性能成本：LFU 比 LRU 内存占用高约 10%，但命中率更优。避免频繁触发淘汰（如设置 maxmemory-policy noeviction 强制报错）。
四、监控与调优
- 关键指标：
- bash
redis-cli info stats | grep evicted_keys # 查看淘汰次数
redis-cli info memory | grep maxmemory # 内存使用情况调优示例：conf
maxmemory 1gb
maxmemory-policy allkeys-lfu
maxmemory-samples 10 # 提高 LRU 精准度
lfu-log-factor 5 # 加快低频数据淘汰五、总结建议
- 首选 LFU：若业务数据访问频率差异明显，优先使用 allkeys-lfu。
- 结合过期时间：对短期数据设置合理 TTL，降低淘汰压力。
- 监控 + 实验：通过 redis-cli monitor 观察淘汰行为，调整策略参数。
如需保留特定数据，可使用 BITFIELD 或设置无过期时间（EXPIRE key -1）。
相关推荐
- Redis合集-使用benchmark性能测试
-
采用开源Redis的redis-benchmark工具进行压测，它是Redis官方的性能测试工具，可以有效地测试Redis服务的性能。本次测试使用Redis官方最新的代码进行编译，详情请参见Redis...
- Java简历总被已读不回?面试挂到怀疑人生?这几点你可能真没做好
-
最近看了几十份简历，发现大部分人不是技术差，而是不会“卖自己”——一、简历死穴：你写的不是经验，是岗位说明书！反面教材：ד使用SpringBoot开发项目”ד负责用户模块功能实现”救命写法：...
- redission YYDS（redission官网）
-
每天分享一个架构知识Redission是一个基于Redis的分布式Java锁框架，它提供了各种锁实现，包括可重入锁、公平锁、读写锁等。使用Redission可以方便地实现分布式锁。red...
- 从数据库行锁到分布式事务:电商库存防超卖的九重劫难与破局之道
-
2023年6月18日我们维护的电商平台在零点刚过3秒就遭遇了严重事故。监控大屏显示某爆款手机SKU_IPHONE13_PRO_MAX在库存仅剩500台时，订单系统却产生了1200笔有效订单。事故复盘发...
- SpringBoot系列——实战11:接口幂等性的形而上思...
-
欢迎关注、点赞、收藏。幂等性不仅是一种技术需求，更是数字文明对确定性追求的体现。在充满不确定性的网络世界中，它为我们建立起可依赖的存在秩序，这或许正是技术哲学最深刻的价值所在。幂等性的本质困境在支付系...
- 如何优化系统架构设计缓解流量压力提升并发性能?Java实战分享
-
如何优化系统架构设计缓解流量压力提升并发性能？Java实战分享在高流量场景下。首先，我需要回忆一下常见的优化策略，比如负载均衡、缓存、数据库优化、微服务拆分这些。不过，可能还需要考虑用户的具体情况，比...
- Java面试题: 项目开发中的有哪些成长?该如何回答
-
在Java面试中，当被问到“项目中的成长点”时，面试官不仅想了解你的技术能力，更希望看到你的问题解决能力、学习迭代意识以及对项目的深度思考。以下是回答的策略和示例，帮助你清晰、有说服力地展示成长点：一...
- 互联网大厂后端必看!Spring Boot 如何实现高并发抢券逻辑?
-
你有没有遇到过这样的情况？在电商大促时，系统上线了抢券活动，结果活动刚一开始，服务器就不堪重负，出现超卖、系统崩溃等问题。又或者用户疯狂点击抢券按钮，最后却被告知无券可抢，体验极差。作为互联网大厂的后...
- 每日一题 |10W QPS高并发限流方案设计(含真实代码)
-
面试场景还原面试官：“如果系统要承载10WQPS的高并发流量，你会如何设计限流方案？”你：“（稳住，我要从限流算法到分布式架构全盘分析）…”一、为什么需要限流？核心矛盾：系统资源（CPU/内存/数据...
- Java面试题:服务雪崩如何解决?90%人栽了
-
服务雪崩是指微服务架构中，由于某个服务出现故障，导致故障在服务之间不断传递和扩散，最终造成整个系统崩溃的现象。以下是一些解决服务雪崩问题的常见方法：限流限制请求速率：通过限流算法（如令牌桶算法、漏桶算...
- 面试题官:高并发经验有吗，并发量多少，如何回复?
-
一、有实际高并发经验（建议结构）直接量化"在XX项目中，系统日活用户约XX万，核心接口峰值QPS达到XX，TPS处理能力为XX/秒。通过压力测试验证过XX并发线程下的稳定性。"技术方案...
- 瞬时流量高并发“保命指南”:这样做系统稳如泰山，老板跪求加薪
-
“系统崩了，用户骂了，年终奖飞了！”——这是多少程序员在瞬时大流量下的真实噩梦？双11秒杀、春运抢票、直播带货……每秒百万请求的冲击，你的代码扛得住吗？2025年了，为什么你的系统一遇高并发就“躺平”...
- 其实很多Java工程师不是能力不够，是没找到展示自己的正确姿势。
-
其实很多Java工程师不是能力不够，是没找到展示自己的正确姿势。比如上周有个小伙伴找我，五年经验但简历全是'参与系统设计''优化接口性能'这种空话。我就问他：你做的秒杀...
- PHP技能评测（php等级考试）
-
公司出了一些自我评测的PHP题目，现将题目和答案记录于此，以方便记忆。1.魔术函数有哪些,分别在什么时候调用?__construct()，类的构造函数__destruct()，类的析构函数__cal...
- 你的简历在HR眼里是青铜还是王者?
-
你的简历在HR眼里是青铜还是王者？兄弟，简历投了100份没反应？面试总在第三轮被刷？别急着怀疑人生，你可能只是踩了这些"隐形求职雷"。帮3630+程序员改简历+面试指导和处理空窗期时间...
欢迎 你 发表评论:
- 一周热门
- 最近发表
- 标签列表
-
- oracle位图索引 (63)
- oracle批量插入数据 (62)
- oracle事务隔离级别 (53)
- oracle 空为0 (50)
- oracle主从同步 (55)
- oracle 乐观锁 (51)
- redis 命令 (78)
- php redis (88)
- redis 存储 (66)
- redis 锁 (69)
- 启动 redis (66)
- redis 时间 (56)
- redis 删除 (67)
- redis内存 (57)
- redis并发 (52)
- redis 主从 (69)
- redis 订阅 (51)
- redis 登录 (54)
- redis 面试 (58)
- 阿里 redis (59)
- redis 搭建 (53)
- redis的缓存 (55)
- lua redis (58)
- redis 连接池 (61)
- redis 限流 (51)