场景:腾讯云数据库 Redis(主从版),业务是电商缓存,包含商品详情、购物车、会话等多类数据,实例规格是 8GB 内存。近一个月内存使用率从 50% 慢慢涨到 85%,监控里 key 数量增长不明显。 现象: 1. 内存使用率持续升高,但按业务估算的缓存数据量远小于当前占用,怀疑存在个别体积很大的 key。 2. 偶尔出现命令耗时尖刺,慢日志里能看到对某些 key 的 HGETALL 和 LRANGE 等命令耗时较长。 3. 设置了淘汰策略,但部分业务 key 没有设置过期时间,不确定是否因此一直累积。 已尝试: 1. 用 INFO memory 看过总内存和碎片率,碎片率不算高。 2. 担心在线上直接执行 KEYS * 会阻塞,没有尝试,也不确定 SCAN 全量扫描的开销。 3. 听说有 redis-cli --bigkeys 和 MEMORY USAGE,但没有在线上用过,不清楚对主节点的影响。 想请教: 1. 在线上实例里,找大 key 的几种方法分别有什么风险?应该在主节点还是从节点上执行,云数据库控制台是否提供内置的大 key 分析功能? 2. 发现大 key 之后,如何安全删除?直接 DEL 一个很大的 Hash 或 List 会不会阻塞?UNLINK 和分批删除各自适用什么场景? 3. 对没有过期时间的 key,怎样批量排查和补设过期时间,同时避免一次性给 Redis 带来过大压力? 4. 从业务设计上如何避免产生大 key,例如购物车、排行榜这类数据应该怎样拆分?
相似问题