1. Redis 内存管理机制全景解读作为后端开发者Redis 的内存管理机制是我们必须掌握的核心知识。在实际工作中我见过太多因为不理解 Redis 内存管理而导致的生产事故有的系统因为内存泄漏导致 Redis 实例崩溃有的因为配置不当导致关键数据被意外淘汰。今天我将结合多年实战经验带大家彻底搞懂 Redis 的过期策略和淘汰策略。1.1 为什么需要内存管理机制Redis 作为内存数据库所有数据都存储在内存中。但内存资源是有限的当内存不足时我们需要解决两个关键问题过期数据清理对于设置了过期时间TTL的 key如何及时清理已经过期的数据内存不足处理当内存用尽时如何决定哪些数据应该被淘汰以腾出空间这两个问题分别由 Redis 的过期策略Expire Policy和内存淘汰策略Eviction Policy来解决。理解它们的原理和区别是合理使用 Redis 的基础。注意过期策略和淘汰策略是完全不同的机制前者针对已过期的数据后者则在内存不足时触发可能淘汰未过期的数据。2. Redis 过期策略深度解析2.1 过期策略的实现原理Redis 采用了双重保险的过期策略结合了惰性删除和定期删除两种机制2.1.1 惰性删除Lazy Expiration惰性删除是 Redis 的第一道防线其工作原理如下触发时机当客户端访问某个 key 时触发执行流程检查 key 是否存在如果存在且设置了过期时间检查是否已过期如果已过期则删除该 key返回 nil 或执行后续操作// 伪代码展示惰性删除逻辑 public Object get(String key) { RedisObject value store.get(key); if (value null) return null; if (value.hasExpire() value.isExpired()) { store.delete(key); return null; } return value; }优点CPU 友好只在访问时进行检查确保返回的数据都是未过期的缺点如果某个 key 长期不被访问即使已过期也会一直占用内存可能导致内存泄漏现象2.1.2 定期删除Active Expiration为了弥补惰性删除的不足Redis 增加了定期删除机制触发时机Redis 服务器每隔 100ms 执行一次执行流程随机抽取 20 个设置了过期时间的 key删除其中已过期的 key如果过期比例超过 25%则重复上述过程最多重复 16 次或耗时超过 25ms 时停止设计考量随机抽样而非全量扫描避免性能问题动态调整扫描力度基于过期比例设置时间上限避免阻塞主线程太久优缺点分析优点能清理长期不访问的僵尸key缺点无法保证实时性可能有几分钟延迟2.2 过期策略的局限性虽然双重机制已经很完善但仍有一些需要注意的地方时间精度问题过期删除不是实时的可能有秒级甚至分钟级延迟内存占用问题大量 key 同时过期可能导致内存瞬时压力性能影响定期删除如果扫描过多 key 会影响 Redis 性能生产建议对于时效性要求极高的场景不要完全依赖 Redis 的过期机制可以在应用层增加校验。3. Redis 内存淘汰策略详解3.1 淘汰策略的触发条件当 Redis 的内存使用达到 maxmemory 参数配置的上限时淘汰策略就会生效。与过期策略不同淘汰策略处理的是内存不足的情况可能会删除未过期的 key。关键配置参数# redis.conf maxmemory 2gb # 最大内存限制 maxmemory-policy allkeys-lru # 淘汰策略 maxmemory-samples 5 # LRU/LFU 采样数量3.2 8 种淘汰策略对比分析Redis 提供了 8 种淘汰策略我们可以根据业务特点选择合适的策略策略作用范围淘汰规则适用场景注意事项noeviction所有 key不淘汰新写入报错数据绝对不能丢失的场景必须确保内存足够allkeys-lru所有 key最近最少使用通用缓存场景推荐可能淘汰热点数据volatile-lru仅带 TTL 的 key最近最少使用混合存储缓存持久数据缓存 key 必须设 TTLallkeys-lfu所有 key最不经常使用访问频率差异大的场景Redis 4.0volatile-lfu仅带 TTL 的 key最不经常使用同上但只淘汰缓存Redis 4.0allkeys-random所有 key随机删除无明确访问模式可能淘汰热点数据volatile-random仅带 TTL 的 key随机删除同上但只淘汰缓存缓存 key 必须设 TTLvolatile-ttl仅带 TTL 的 keyTTL 最短优先优先清理即将过期的数据需要合理设置 TTL3.3 LRU 与 LFU 算法深入解析3.3.1 LRU最近最少使用Redis 实现的是近似 LRU 算法而非精确 LRU。这是因为精确 LRU 需要维护所有 key 的访问时间戳内存开销太大。实现特点每次访问 key 时记录当前时间精度为秒淘汰时随机采样 N 个 key默认 5 个选择其中最久未使用的淘汰可通过 maxmemory-samples 调整采样数量越大越接近精确 LRU适用场景短期热点数据如新闻、促销商品访问模式随时间变化的场景3.3.2 LFU最不经常使用LFU 是 Redis 4.0 引入的新策略基于访问频率而非最近访问时间。实现特点为每个 key 维护一个访问计数器计数器会随时间衰减避免历史访问影响太大淘汰时选择访问频率最低的 key适用场景有明显热点和冷门区分的场景如热门商品 vs 冷门商品长期稳定的访问模式3.4 淘汰策略的选择建议根据多年经验我总结出以下选择指南纯缓存系统优先选择 allkeys-lru混合存储系统缓存持久数据使用 volatile-lru并确保缓存 key 都设置了 TTL数据绝对不能丢使用 noeviction但要确保有完善的内存监控和告警特殊访问模式热点明显考虑 allkeys-lfu无明确模式allkeys-random重要提示无论选择哪种策略都必须设置 maxmemory不设内存上限的 Redis 就像没有刹车的汽车迟早会出问题。4. Spring Boot 实战配置4.1 基础配置示例在 Spring Boot 中配置 Redis 内存策略spring: redis: host: 127.0.0.1 port: 6379 # 其他配置...对应的 Redis 服务器配置redis.confmaxmemory 4gb maxmemory-policy allkeys-lru4.2 不同业务场景的实现4.2.1 纯缓存场景// 设置缓存数据推荐设置较长的TTL作为兜底 public void cacheProduct(Product product) { String key product: product.getId(); String json objectMapper.writeValueAsString(product); // 设置24小时过期即使淘汰策略失效也会最终过期 redisTemplate.opsForValue().set(key, json, 24, TimeUnit.HOURS); }4.2.2 混合存储场景// 永久数据不设置TTL public void saveUserToken(Long userId, String token) { String key user:token: userId; redisTemplate.opsForValue().set(key, token); } // 缓存数据设置TTL public void cacheProductDetail(Long productId, ProductDetail detail) { String key product:detail: productId; String json objectMapper.writeValueAsString(detail); redisTemplate.opsForValue().set(key, json, 30, TimeUnit.MINUTES); }对应的 Redis 配置maxmemory-policy volatile-lru4.3 常见错误及避免方法错误1未设置 maxmemory现象Redis 内存持续增长最终被系统 OOM Killer 杀死解决方案# 设置为物理内存的70%-80% maxmemory 12gb错误2策略选择不当现象重要数据被意外淘汰或内存不足时服务不可用解决方案评估数据重要性选择合适的淘汰策略对重要数据做持久化备份错误3Big Key 问题现象淘汰大 key 时阻塞主线程导致服务延迟解决方案定期运行redis-cli --bigkeys检查拆分大 key 为多个小 key对不必要的大 key 设置适当 TTL5. 生产环境最佳实践5.1 容量规划建议内存设置生产环境必须设置 maxmemory建议值为物理内存的 70%-80%留出空间给系统和 fork 操作监控指标# 查看内存和淘汰情况 redis-cli info memory # 关键指标 # used_memory当前内存使用量 # maxmemory内存上限 # evicted_keys累计淘汰key数突增说明内存压力大 # expired_keys累计过期key数5.2 性能优化技巧过期时间设置避免大量 key 在同一时间点过期可添加随机偏移量示例// 设置30分钟±5分钟的随机过期时间 int expireMinutes 30 ThreadLocalRandom.current().nextInt(-5, 5); redisTemplate.opsForValue().set(key, value, expireMinutes, TimeUnit.MINUTES);采样数调整# 提高LRU/LFU精度但会增加CPU开销 maxmemory-samples 105.3 故障排查指南问题1为什么过期 key 还能查到排查步骤检查 key 的实际状态redis-cli TTL key_name-2key 不存在-1key 存在但未设置过期时间0剩余生存时间确认 Redis 的过期删除是否正常工作redis-cli info stats | grep expired_keys问题2内存使用接近上限但未触发淘汰可能原因设置了 noeviction 策略所有 key 都没有设置过期时间volatile-* 策略失效解决方案检查淘汰策略配置确保有足够的 key 可以被淘汰6. 高级话题与未来演进6.1 Redis 内存管理的底层实现Redis 的过期机制实际上使用了两种数据结构过期字典保存所有设置了 TTL 的 key 及其过期时间戳时间事件实现定期删除的扫描逻辑这种设计实现了空间和时间的高效平衡使得检查 key 是否过期只需 O(1) 时间复杂度内存开销控制在合理范围内6.2 最新版本改进Redis 7.0 在内存管理方面有一些值得关注的改进更高效的 LRU 实现减少了内存占用改进的 LFU 算法更准确地反映访问频率动态调整淘汰策略支持运行时修改策略而不重启6.3 与其他技术的结合在实际系统中Redis 的内存管理往往需要与其他技术配合与持久化结合RDB 持久化会忽略已过期的 keyAOF 会记录 DEL 命令来删除过期 key与集群模式结合集群模式下每个节点独立管理内存需要均匀分配内存负载7. 总结回顾经过上面的详细讲解我们可以总结出 Redis 内存管理的几个关键点双重过期策略惰性删除定期删除组合使用兼顾性能和内存效率多样化淘汰策略8 种策略适应不同业务场景LRU 和 LFU 各有优劣必须设置 maxmemory这是生产环境的基本要求监控至关重要关注内存使用、淘汰数量等关键指标最后分享一个我在实际工作中总结的配置检查清单[ ] 是否设置了合理的 maxmemory[ ] 选择的淘汰策略是否符合业务特点[ ] 是否对重要数据做了持久化备份[ ] 是否有监控内存使用和淘汰情况的机制[ ] 是否避免了 big key 问题理解并合理配置 Redis 的内存管理机制可以显著提高系统的稳定性和性能。希望本文能帮助你在实际工作中更好地使用 Redis。
1. Redis 内存管理机制全景解读作为后端开发者Redis 的内存管理机制是我们必须掌握的核心知识。在实际工作中我见过太多因为不理解 Redis 内存管理而导致的生产事故有的系统因为内存泄漏导致 Redis 实例崩溃有的因为配置不当导致关键数据被意外淘汰。今天我将结合多年实战经验带大家彻底搞懂 Redis 的过期策略和淘汰策略。1.1 为什么需要内存管理机制Redis 作为内存数据库所有数据都存储在内存中。但内存资源是有限的当内存不足时我们需要解决两个关键问题过期数据清理对于设置了过期时间TTL的 key如何及时清理已经过期的数据内存不足处理当内存用尽时如何决定哪些数据应该被淘汰以腾出空间这两个问题分别由 Redis 的过期策略Expire Policy和内存淘汰策略Eviction Policy来解决。理解它们的原理和区别是合理使用 Redis 的基础。注意过期策略和淘汰策略是完全不同的机制前者针对已过期的数据后者则在内存不足时触发可能淘汰未过期的数据。2. Redis 过期策略深度解析2.1 过期策略的实现原理Redis 采用了双重保险的过期策略结合了惰性删除和定期删除两种机制2.1.1 惰性删除Lazy Expiration惰性删除是 Redis 的第一道防线其工作原理如下触发时机当客户端访问某个 key 时触发执行流程检查 key 是否存在如果存在且设置了过期时间检查是否已过期如果已过期则删除该 key返回 nil 或执行后续操作// 伪代码展示惰性删除逻辑 public Object get(String key) { RedisObject value store.get(key); if (value null) return null; if (value.hasExpire() value.isExpired()) { store.delete(key); return null; } return value; }优点CPU 友好只在访问时进行检查确保返回的数据都是未过期的缺点如果某个 key 长期不被访问即使已过期也会一直占用内存可能导致内存泄漏现象2.1.2 定期删除Active Expiration为了弥补惰性删除的不足Redis 增加了定期删除机制触发时机Redis 服务器每隔 100ms 执行一次执行流程随机抽取 20 个设置了过期时间的 key删除其中已过期的 key如果过期比例超过 25%则重复上述过程最多重复 16 次或耗时超过 25ms 时停止设计考量随机抽样而非全量扫描避免性能问题动态调整扫描力度基于过期比例设置时间上限避免阻塞主线程太久优缺点分析优点能清理长期不访问的僵尸key缺点无法保证实时性可能有几分钟延迟2.2 过期策略的局限性虽然双重机制已经很完善但仍有一些需要注意的地方时间精度问题过期删除不是实时的可能有秒级甚至分钟级延迟内存占用问题大量 key 同时过期可能导致内存瞬时压力性能影响定期删除如果扫描过多 key 会影响 Redis 性能生产建议对于时效性要求极高的场景不要完全依赖 Redis 的过期机制可以在应用层增加校验。3. Redis 内存淘汰策略详解3.1 淘汰策略的触发条件当 Redis 的内存使用达到 maxmemory 参数配置的上限时淘汰策略就会生效。与过期策略不同淘汰策略处理的是内存不足的情况可能会删除未过期的 key。关键配置参数# redis.conf maxmemory 2gb # 最大内存限制 maxmemory-policy allkeys-lru # 淘汰策略 maxmemory-samples 5 # LRU/LFU 采样数量3.2 8 种淘汰策略对比分析Redis 提供了 8 种淘汰策略我们可以根据业务特点选择合适的策略策略作用范围淘汰规则适用场景注意事项noeviction所有 key不淘汰新写入报错数据绝对不能丢失的场景必须确保内存足够allkeys-lru所有 key最近最少使用通用缓存场景推荐可能淘汰热点数据volatile-lru仅带 TTL 的 key最近最少使用混合存储缓存持久数据缓存 key 必须设 TTLallkeys-lfu所有 key最不经常使用访问频率差异大的场景Redis 4.0volatile-lfu仅带 TTL 的 key最不经常使用同上但只淘汰缓存Redis 4.0allkeys-random所有 key随机删除无明确访问模式可能淘汰热点数据volatile-random仅带 TTL 的 key随机删除同上但只淘汰缓存缓存 key 必须设 TTLvolatile-ttl仅带 TTL 的 keyTTL 最短优先优先清理即将过期的数据需要合理设置 TTL3.3 LRU 与 LFU 算法深入解析3.3.1 LRU最近最少使用Redis 实现的是近似 LRU 算法而非精确 LRU。这是因为精确 LRU 需要维护所有 key 的访问时间戳内存开销太大。实现特点每次访问 key 时记录当前时间精度为秒淘汰时随机采样 N 个 key默认 5 个选择其中最久未使用的淘汰可通过 maxmemory-samples 调整采样数量越大越接近精确 LRU适用场景短期热点数据如新闻、促销商品访问模式随时间变化的场景3.3.2 LFU最不经常使用LFU 是 Redis 4.0 引入的新策略基于访问频率而非最近访问时间。实现特点为每个 key 维护一个访问计数器计数器会随时间衰减避免历史访问影响太大淘汰时选择访问频率最低的 key适用场景有明显热点和冷门区分的场景如热门商品 vs 冷门商品长期稳定的访问模式3.4 淘汰策略的选择建议根据多年经验我总结出以下选择指南纯缓存系统优先选择 allkeys-lru混合存储系统缓存持久数据使用 volatile-lru并确保缓存 key 都设置了 TTL数据绝对不能丢使用 noeviction但要确保有完善的内存监控和告警特殊访问模式热点明显考虑 allkeys-lfu无明确模式allkeys-random重要提示无论选择哪种策略都必须设置 maxmemory不设内存上限的 Redis 就像没有刹车的汽车迟早会出问题。4. Spring Boot 实战配置4.1 基础配置示例在 Spring Boot 中配置 Redis 内存策略spring: redis: host: 127.0.0.1 port: 6379 # 其他配置...对应的 Redis 服务器配置redis.confmaxmemory 4gb maxmemory-policy allkeys-lru4.2 不同业务场景的实现4.2.1 纯缓存场景// 设置缓存数据推荐设置较长的TTL作为兜底 public void cacheProduct(Product product) { String key product: product.getId(); String json objectMapper.writeValueAsString(product); // 设置24小时过期即使淘汰策略失效也会最终过期 redisTemplate.opsForValue().set(key, json, 24, TimeUnit.HOURS); }4.2.2 混合存储场景// 永久数据不设置TTL public void saveUserToken(Long userId, String token) { String key user:token: userId; redisTemplate.opsForValue().set(key, token); } // 缓存数据设置TTL public void cacheProductDetail(Long productId, ProductDetail detail) { String key product:detail: productId; String json objectMapper.writeValueAsString(detail); redisTemplate.opsForValue().set(key, json, 30, TimeUnit.MINUTES); }对应的 Redis 配置maxmemory-policy volatile-lru4.3 常见错误及避免方法错误1未设置 maxmemory现象Redis 内存持续增长最终被系统 OOM Killer 杀死解决方案# 设置为物理内存的70%-80% maxmemory 12gb错误2策略选择不当现象重要数据被意外淘汰或内存不足时服务不可用解决方案评估数据重要性选择合适的淘汰策略对重要数据做持久化备份错误3Big Key 问题现象淘汰大 key 时阻塞主线程导致服务延迟解决方案定期运行redis-cli --bigkeys检查拆分大 key 为多个小 key对不必要的大 key 设置适当 TTL5. 生产环境最佳实践5.1 容量规划建议内存设置生产环境必须设置 maxmemory建议值为物理内存的 70%-80%留出空间给系统和 fork 操作监控指标# 查看内存和淘汰情况 redis-cli info memory # 关键指标 # used_memory当前内存使用量 # maxmemory内存上限 # evicted_keys累计淘汰key数突增说明内存压力大 # expired_keys累计过期key数5.2 性能优化技巧过期时间设置避免大量 key 在同一时间点过期可添加随机偏移量示例// 设置30分钟±5分钟的随机过期时间 int expireMinutes 30 ThreadLocalRandom.current().nextInt(-5, 5); redisTemplate.opsForValue().set(key, value, expireMinutes, TimeUnit.MINUTES);采样数调整# 提高LRU/LFU精度但会增加CPU开销 maxmemory-samples 105.3 故障排查指南问题1为什么过期 key 还能查到排查步骤检查 key 的实际状态redis-cli TTL key_name-2key 不存在-1key 存在但未设置过期时间0剩余生存时间确认 Redis 的过期删除是否正常工作redis-cli info stats | grep expired_keys问题2内存使用接近上限但未触发淘汰可能原因设置了 noeviction 策略所有 key 都没有设置过期时间volatile-* 策略失效解决方案检查淘汰策略配置确保有足够的 key 可以被淘汰6. 高级话题与未来演进6.1 Redis 内存管理的底层实现Redis 的过期机制实际上使用了两种数据结构过期字典保存所有设置了 TTL 的 key 及其过期时间戳时间事件实现定期删除的扫描逻辑这种设计实现了空间和时间的高效平衡使得检查 key 是否过期只需 O(1) 时间复杂度内存开销控制在合理范围内6.2 最新版本改进Redis 7.0 在内存管理方面有一些值得关注的改进更高效的 LRU 实现减少了内存占用改进的 LFU 算法更准确地反映访问频率动态调整淘汰策略支持运行时修改策略而不重启6.3 与其他技术的结合在实际系统中Redis 的内存管理往往需要与其他技术配合与持久化结合RDB 持久化会忽略已过期的 keyAOF 会记录 DEL 命令来删除过期 key与集群模式结合集群模式下每个节点独立管理内存需要均匀分配内存负载7. 总结回顾经过上面的详细讲解我们可以总结出 Redis 内存管理的几个关键点双重过期策略惰性删除定期删除组合使用兼顾性能和内存效率多样化淘汰策略8 种策略适应不同业务场景LRU 和 LFU 各有优劣必须设置 maxmemory这是生产环境的基本要求监控至关重要关注内存使用、淘汰数量等关键指标最后分享一个我在实际工作中总结的配置检查清单[ ] 是否设置了合理的 maxmemory[ ] 选择的淘汰策略是否符合业务特点[ ] 是否对重要数据做了持久化备份[ ] 是否有监控内存使用和淘汰情况的机制[ ] 是否避免了 big key 问题理解并合理配置 Redis 的内存管理机制可以显著提高系统的稳定性和性能。希望本文能帮助你在实际工作中更好地使用 Redis。
