Redis中有大量未设置过期时间的缓存应该如何处理?

本文介绍了解决因未设置过期时间而导致Redis内存过高的问题。通过批量删除无过期时间的缓存、更改Redis淘汰策略等手段,有效降低Redis内存占用。

问题

Redis集群因为开发人员问题,放入过多的没有设备过期时间的缓存,导致Redis内存使用过高。

解决方案

  1. 把过期的KEY找出来,批量删除。
  • 安装Redis-cli (生产环境大部分都是集群,或者云服务,不要在安装Redis的机器上操作),下面是Centos系统操作脚本
    # 安装基础依赖
    yum install -y gcc wget
    # 下载包
    wget http://download.redis.io/redis-stable.tar.gz
    # 解压
    tar xvzf redis-stable.tar.gz
    cd redis-stable
    # 编译
    make redis-cli
    # 
    sudo cp src/redis-cli /usr/local/bin/
    
  • 执行批量删除脚本
     redis-cli -h host -p port -a password  keys "ABC*" |xargs  redis-cli -h host -p port -a password  keys "ABC*" del
    
    -h Redis服务器地址
    -p Redis服务端口
    -a Redis服务密码
    keys 查询key
  1. 业务切换Redis DB到其他逻辑库,把有问题的库的数据全部清除。
flushdb   // 清除当前数据库的所有keys
flushall    // 清除所有数据库的所有keys
  1. 修改程序,设置Key过期时间,并且设置Redis淘汰策略为allkeys-lru,这个需要自己评估一下Redis是否有特殊用法。
    volatile-lru,针对设置了过期时间的key,使用lru算法进行淘汰。
    allkeys-lru,针对所有key使用lru算法进行淘汰。
    volatile-lfu,针对设置了过期时间的key,使用lfu算法进行淘汰。
    allkeys-lfu,针对所有key使用lfu算法进行淘汰。
    volatile-random,从所有设置了过期时间的key中使用随机淘汰的方式进行淘汰。
    allkeys-random,针对所有的key使用随机淘汰机制进行淘汰。
    volatile-ttl,删除生存时间最近的一个键。
    noeviction(默认),不删除键,值返回错误。
<think> 我们正在讨论的是Redis键的过期时间设置多少合适的问题。根据之前的对话,我们已经知道Redis默认不会设置过期时间(即永久有效),而现在用户想知道如何设置合理的过期时间。 关键点: 1. 过期时间设置没有统一标准,需要根据业务场景具体分析 2. 主要考虑因素:数据更新频率、数据重要性、缓存穿透风险、系统资源限制 我将从以下几个方面展开: 1. 不同业务场景的典型设置 2. 设置过期时间的策略与技巧 3. 过期时间设置不当的风险 4. 相关配置建议 另外,根据引用资料,我们注意到: - 引用[1]和[2]介绍了设置过期时间的命令(EXPIRE, SETEX等) - 引用[3]警告不要将大量key过期时间设置为同一时刻,以免造成CPU压力 - 引用[4]再次强调了过期时间的特性(只能通过特定命令清除) 因此,在回答中需要融入这些关键信息,并在适当位置标注引用。 </think> ### Redis过期时间设置的最佳实践 Redis键的过期时间设置需根据**业务场景**和**数据特性**动态调整,没有固定标准值。以下是具体建议: #### 📊 综合设置原则 1. **短期数据**(验证码/临时会话) - **建议范围**:$30s \sim 10min$ - 例如:短信验证码设为$120s$[^1][^2] 2. **中期缓存**(热点数据/DB查询结果) - **建议范围**:$10min \sim 24h$ - 结合**缓存穿透防护**:设置$5 \sim 30min$随机偏移量(如实际$600s$,设$600 \pm 60s$)[^3] 3. **长期数据**(配置信息) - **建议范围**:$24h \sim 7d$ - 需配合**主动更新机制**:数据变更时通过`DEL`或重新`SETEX`刷新[^4] --- #### ⚠️ 关键注意事项 1. **避免批量同时间过期** - 大量键同时过期会引发CPU突增[^3] - **解决方案**: $$ T_{expire} = T_{base} + \text{rand}(0, T_{jitter}) $$ 其中$T_{jitter}$建议为$T_{base}$的$10\% \sim 20\%$ 2. **内存淘汰策略联动** ```conf maxmemory-policy volatile-ttl # 优先淘汰即将过期的键 ``` 当内存达到`maxmemory`时,该策略可减少淘汰有效数据风险[^4] 3. **持久化影响** - RDB:过期键不会持久化到快照 - AOF:过期时追加`DEL`命令到日志 --- #### 🔧 实践案例 ```python # Python示例:设置电商商品缓存(基础30分钟+随机抖动) import redis import random r = redis.Redis() product_id = "p10086" base_ttl = 1800 # 基础30分钟 jitter = random.randint(0, 300) # 0~5分钟随机抖动 r.setex(f"product:{product_id}", base_ttl + jitter, product_data) ``` --- ### 📌 总结建议 | 数据类型 | 典型场景 | 推荐过期时间 | 特殊处理 | |----------------|------------------------|--------------------|------------------------| | 瞬时数据 | 验证码、锁 | $<5min$ | 严格过期 | | 高频读取数据 | 热点商品、资讯 | $30min \sim 2h$ | 添加随机抖动 | | 低频更新数据 | 配置信息、黑白名单 | $24h \sim 7d$ | 变更时主动刷新 | | 持久化数据 | 用户基础信息 | 永不过期 | 配合内存淘汰策略 | --- ### 相关问题 1. Redis的`EXPIRE`命令和`PERSIST`命令如何配合使用?[^2] 2. 如何监控Redis中即将过期的键数量? 3. 为什么设置过期时间的键在内存不足时可能被提前淘汰? 4. Redis的惰性删除和定期删除机制如何影响过期时间准确性?[^3] 5. 在分布式系统中如何避免缓存雪崩与过期时间设置的关系?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值