## 01、痛点

我是老李。前一阵子凌晨两点，运维群里突然告警：订单服务 Redis 内存使用率从 65% 一路涨到 92%，接口响应从 90ms 变成 2.1s，部分请求直接超时。我们上去一看，Redis 里躺着 7 亿多个 Key，其中超过 4 亿个没有设置 TTL；命名更是五花八门，有 `order_1001`、`mall_order_1001`、`mall:order:1001`，还有 `tmp_xxx_20230101`。想按前缀清理，结果前缀有十几种；想定位哪个业务写得多，完全没有头绪。更可怕的是，热 Key 和大 Key 也同时出现，一个商品详情 Key 有 3MB，一个活动 Key 每秒被读 2 万次，集群分片直接被打歪。

这就是我今天想聊的事：Redis 生产系统最常见的问题，往往不是不会 SET，而是 Key 命名混乱、TTL 不合理、热 Key、大 Key 和生命周期失控。命令本身不难，难的是把 Key 当成工程对象去设计。

## 02、是什么

先厘清几个概念。Redis 是内存键值数据库，所有能力最终都围绕 Key 展开：读写、过期、持久化、集群分片，都靠 Key 定位。Key Namespace 可以理解成命名空间，就是通过前缀把 Key 按业务语义分组，例如 `mall:user:10001` 和 `mall:user:10002` 属于同一个用户命名空间。TTL（Time To Live）表示 Key 的有效期，单位可以是秒或毫秒；设置后，Redis 会在到期后回收。

Redis 的过期策略不是单一机制，而是两种方式配合。惰性删除：当客户端访问某个 Key 时，Redis 先检查它是否过期，如果过期就立即删除并返回空。定期删除：Redis 内部默认每 100 毫秒随机抽取一部分带过期时间的 Key，判断是否过期并删除。惰性删除省 CPU 但长期不访问的 Key 会一直占内存；定期删除避免内存无限增长，又不会像全量扫描那样阻塞主线程。

除了 TTL，还要理解大 Key 和热 Key。大 Key 通常指单个 Key 的 value 过大，比如一个 String 存了 2MB 的 JSON，或者一个 Hash 有几十万个 field；热 Key 则指极少数 Key 承载了大部分读写流量。它们都会拖慢 Redis，甚至影响集群稳定。

## 03、为什么

为什么 Key 设计这么重要？我总结成四个成本。

第一，命名混乱带来运维成本。Key 没有统一规范，就无法按前缀统计、监控、清理。比如想删除某个活动产生的临时数据，如果有的叫 `act_1001`、有的叫 `tmp_act_1001`、有的叫 `activity:1001`，批量操作根本做不了，只能靠人肉或危险的全库 SCAN。

第二，TTL 不合理带来内存和稳定性成本。不设 TTL，内存会持续膨胀，尤其像验证码、会话、临时锁这类数据，业务早就没用了，Key 还占着内存。TTL 设置过短，缓存频繁失效，请求直接打到数据库；而大量 Key 在同一时刻过期，又可能引发缓存雪崩。

第三，热 Key 和大 Key 带来性能成本。热 Key 会把请求集中到单个分片，导致集群负载不均；大 Key 会导致网络传输变慢、持久化阻塞、内存碎片增加。

第四，生命周期失控带来安全与数据一致性风险。比如登录 Token 永不过期，一旦泄露可长期使用；缓存数据和数据库不一致，但 Key 又从不更新或删除。可以说，Key 设计不是锦上添花，而是生产稳定性的底座。

## 04、架构

要把 Key 管好，我建议在架构层面建立四层设计：命名规范、TTL 矩阵、热/大 Key 治理、版本升级策略。

命名规范统一使用 `业务:对象:id[:维度]`。业务段用简短英文标识，如 `mall`、`pay`、`im`；对象段描述数据实体，如 `user`、`product`、`token`；id 是唯一标识；最后可以追加维度，如 `mall:user:10001:cart`、`mall:product:20001:detail`。这样做的好处是前缀可扫描、职责清晰、冲突概率低。禁止使用无意义前缀 `tmp`、`test`、`aaa`，禁止把 ID 拼成多种格式。

TTL 矩阵要按业务对象提前定义。例如登录 Token 30 分钟，用户基础信息 1 小时，商品详情 30 分钟，基础配置 10 分钟，临时数据 5 分钟；不可变数据可以设置较长 TTL，但必须带版本维度。所有 Key 都必须有默认 TTL，不允许“永久不过期”的裸 Key。

热 Key 治理要融入 Key 设计。可以在设计时预留副本维度，例如 `mall:product:20001:detail:0`、`mall:product:20001:detail:1`，客户端按随机数读取不同副本；也可以接入本地缓存，减少 Redis 请求。大 Key 治理则要拆分集合，例如购物车不要用一个巨大 Hash，而是拆成 `mall:cart:userId:itemId`，或者对 value 做压缩，限制列表长度。

版本升级策略同样不能缺位。建议在 Key 前缀中保留版本位，如 `mall:v2:user:10001`，或把版本作为维度追加在最后。升级时新版本写新 Key，读取时先读新 Key，回退读旧 Key，通过灰度逐步切换，旧版本等 TTL 到期自然清理。这样能避免修改 value 结构导致老版本客户端反序列化失败。

## 05、实战

下面直接上 Spring Boot 落地。生产环境建议优先使用 `StringRedisTemplate`，因为它默认使用字符串序列化器，Key 和 value 都是可读文本。`RedisTemplate` 虽然通用，但默认使用 JDK 序列化器，Key 会变成类似 `\xac\xed\x00\x05t\x00` 的二进制，排障非常难受。如果要用 `RedisTemplate` 存对象，务必自定义 Serializer，通常采用 `StringRedisSerializer` 作为 Key 序列化器，`GenericJackson2JsonRedisSerializer` 作为 value 序列化器。

先写一个配置类：

```java
@Configuration
public class RedisConfig {
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);
        StringRedisSerializer stringSerializer = new StringRedisSerializer();
        GenericJackson2JsonRedisSerializer jsonSerializer = new GenericJackson2JsonRedisSerializer();
        template.setKeySerializer(stringSerializer);
        template.setValueSerializer(jsonSerializer);
        template.setHashKeySerializer(stringSerializer);
        template.setHashValueSerializer(jsonSerializer);
        template.afterPropertiesSet();
        return template;
    }
}
```

再实现登录 Token 30 分钟自动过期。示例使用 `StringRedisTemplate`：

```java
@Service
public class LoginService {
    private final StringRedisTemplate redis;

    public LoginService(StringRedisTemplate redis) {
        this.redis = redis;
    }

    public String createToken(String userId) {
        String token = UUID.randomUUID().toString().replace("-", "");
        String key = String.format("mall:token:%s", token);
        redis.opsForValue().set(key, userId, 30, TimeUnit.MINUTES);
        return token;
    }

    public String getUserId(String token) {
        String key = String.format("mall:token:%s", token);
        String userId = redis.opsForValue().get(key);
        if (userId != null) {
            redis.expire(key, 30, TimeUnit.MINUTES);
        }
        return userId;
    }

    public Long getTokenTtl(String token) {
        return redis.getExpire(String.format("mall:token:%s", token), TimeUnit.MINUTES);
    }
}
```

这里 `expire()` 用于设置过期时间，`getExpire()` 用于查询剩余 TTL。如果希望 Token 在用户活跃时自动续期，可以在读取成功后调用 `expire()` 重置 30 分钟；如果只要求固定 30 分钟过期，则读取时不续期。用户信息 Key 可以写为 `mall:user:10001`，商品详情 Key 写为 `mall:product:20001`。写入时同样带上 TTL，比如用户信息 1 小时：`redis.opsForValue().set("mall:user:10001", userJson, 1, TimeUnit.HOURS);`。这样从命令到业务都可控。

## 06、洞见

如果上升到 1 亿用户、100 个业务模块，Key 设计就不只是格式问题，而是容量、分片和演进问题。

先说命名空间。100 个业务模块必须建立短码字典，例如用户模块用 `mu`、商品模块用 `mp`、Token 模块用 `mt`，然后严格按照 `业务:对象:id:维度` 落地。比如 `mu:user:10001:profile`、`mp:product:20001:detail`、`mt:token:xxx`。不能直接把完整业务名写进 Key，否则 Key 变长，内存占用增加；也不能用数字缩写到不可读，要平衡可读性和长度。

再说分片。Redis Cluster 只根据 Key 计算 CRC16 分片。如果希望同一用户的多个 Key 落到同一分片，可以使用哈希标签：`mu:user:{10001}:profile` 和 `mu:user:{10001}:cart`，这样只有 `{}` 内的 `10001` 参与分片计算。但要注意，如果某个用户是超级热点，这种设计会加剧分片倾斜；此时应配合本地缓存或副本 Key 打散。

TTL 设计也要分级。1 亿用户假设平均每用户产生 10 个 Key，就是 10 亿 Key。每个 Key 的元数据、过期索引都会占内存。因此必须按数据冷热设置 TTL：Token 30 分钟，用户基础信息 1 小时，用户详情 24 小时，商品详情 30 分钟，库存 5 到 10 秒或事件失效，计数榜单 1 分钟。并且加 5% 到 10% 的随机抖动，避免同一秒大量过期。

版本升级策略是重点。Key 结构变更不能直接在原 Key 上改。建议在命名空间中加入版本：`mu:v2:user:10001:profile`。升级时新版本双写，读取端先读新版本，未命中再回退旧版本，然后用灰度比例逐步切流。旧版本 Key 会在 TTL 到期后自然消失，不需要全量删除。这样即使 1 亿用户量级，也能平滑演进。

## 07、行动

行动比理论更重要。给你一份可以立刻执行的清单：

1. 盘点现有 Key：用 `SCAN` 代替 `KEYS *`，按前缀统计 Key 数量、TTL 情况，找出无 TTL 的 Key 和超过 1MB 的大 Key。
2. 建立命名字典：把业务模块、对象、维度及缩写登记成表，所有新增 Key 必须从字典取值，代码评审时强制校验前缀。
3. 所有 Key 必须设置 TTL：禁止裸 `set`；如需长期保存，设置 7 天或 30 天并带版本。
4. 热 Key 接入本地缓存：高频商品、配置类数据加 Caffeine 或 Guava 本地缓存，减少 Redis 压力。
5. 大 Key 拆分：单个 String 不超过 100KB，单个集合不超过 5000 个元素；超过就拆分或压缩。
6. 建立生命周期看板：监控无 TTL Key、即将过期 Key、热点 Key、大 Key 数量，每周巡检一次。
7. 版本升级常态化：变更前先评估 Key 结构，严格执行双写、读取回退、灰度切换三步。

## 08、小结

Redis 不是简单的 set/get 工具，它更像一个共享的高性能内存结构。Key 命名、TTL 和生命周期治理，决定了系统在流量增长后是稳定还是失控。不要等到凌晨告警再开始整理 Key。从下一个需求开始，把 Key 当成 API 一样设计：有命名规范、有默认 TTL、有版本、有生命周期看板。这样，SET 才不只是 SET。

## 09、链接与概念说明

最后把本文涉及的核心概念再串一遍：

- Key Namespace：通过前缀对 Key 进行逻辑分组，如 `mall:user` 表示用户服务命名空间。
- TTL：Key 的存活时间，单位秒或毫秒；到达后由 Redis 回收。
- 惰性删除：访问 Key 时发现过期立即删除。
- 定期删除：Redis 定时随机采样部分带 TTL 的 Key，过期则删除。
- 热 Key：读写流量高度集中的 Key，会导致分片倾斜。
- 大 Key：value 过大或集合元素过多的 Key，可能拖慢网络、持久化和内存分配。
- `StringRedisTemplate`：Spring 提供的字符串 Key-Value 模板，默认可读。
- `RedisTemplate`：更通用的 Redis 操作模板，需要自定义 Serializer 避免二进制 Key。
- Serializer：序列化器，常见有 `StringRedisSerializer`、`GenericJackson2JsonRedisSerializer`。
- `expire()` / `getExpire()`：分别用于设置和查询 Key 的 TTL。

建议进一步阅读 Redis 官方文档中关于 expire 命令、过期策略和 Cluster hash tags 的章节，以及 Spring Data Redis 参考手册对序列化器的说明。

我是老李。前一阵子凌晨两点，运维群里突然告警：订单服务 Redis 内存使用率从 65% 一路涨到 92%，接口响应从 90ms 变成 2.1s，部分请求直接超时。我们上去一看，Redis 里躺着 7 亿多个 Key，其中超过 4 亿个没有设置 TTL；命名更是五花八门，有 order_1001、mall_order_1001、mall:order:1001，还有 tmp_xxx_20230101。想按前缀清理，结果前缀有十几种；想定位哪个业务写得多，完全没有头绪。更可怕的是，热 Key 和大 Key 也同时出现，一个商品详情 Key 有 3MB，一个活动 Key 每秒被读 2 万次，集群分片直接被打歪。

《Redis 8.10 + Spring Boot 实战》第2招 Key 与 TTL——Redis 真正的第一课不是数据结构，而是 Key 设计

生产环境 Redis 问题多半不在 SET，而在 Key 命名混乱、TTL 不合理和生命周期失控。本文结合 Spring Boot 实战，给出一套可落地的 Ke

架构师

数据库

后端

编程语言

Redis生产事故警示：7亿Key中4亿无TTL导致服务超时，本文详解Key命名规范、TTL矩阵、热/大Key治理及版本升级四大架构设计，提供SpringBoot实战代码，涵盖StringRedisTemplate配置、Token自动过期、分片哈希标签等落地技巧，助你构建稳定高效的Redis缓存体系。

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Redis 8.10 + Spring Boot 实战》第2招 Key 与 TTL——Redis 真正的第一课不是数据结构，而是 Key 设计-腾讯云开发者社区-腾讯云

《Redis 8.10 + Spring Boot 实战》第2招 Key 与 TTL——Redis 真正的第一课不是数据结构，而是 Key 设计

《Redis 8.10 + Spring Boot 实战》第2招 Key 与 TTL——Redis 真正的第一课不是数据结构，而是 Key 设计

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐