3. Redis基础数据结构选型：String、Hash、Set在令牌存储中的适用场景
在认证授权平台的令牌刷新接口中，Redis 的数据结构选择直接影响存储效率、查询性能和过期管理能力。String、Hash、Set 三种基础结构各有其适用边界，选型错误会导致内存浪费、查询延迟升高或功能缺失。本节从令牌存储的实际需求出发，逐一分析三种结构的优劣，并给出明确的选型建议。
3.1 令牌存储的核心需求
在分析数据结构之前，先明确令牌存储必须满足的几项关键需求：
- 快速单点查询：根据 access_token 或 refresh_token 的值，毫秒级返回用户身份、过期时间、权限范围等信息。
- 过期自动清理：令牌具有 TTL，Redis 需要原生支持键级过期，避免手动轮询删除。
- 关联数据存储：一个令牌通常关联多个字段（用户ID、角色、客户端ID、scope 等），需要支持部分字段更新（如刷新后延长过期时间）。
- 去重与集合操作：某些场景需要记录用户的所有活跃令牌，或批量撤销某用户的全部令牌。
选型原则：优先满足查询性能与过期管理，其次考虑内存效率和字段灵活性。不要为了“通用”而选择不适合的结构。
3.2 三种数据结构对比总览
| 特性 | String | Hash | Set |
|---|---|---|---|
| 存储模型 | 键 → 单值（JSON 字符串） | 键 → 多个 field-value 对 | 键 → 无序字符串集合 |
| 单点查询性能 | O(1) 极高 | O(1) 极高 | 不支持单点查询（需遍历） |
| 部分字段更新 | 不支持（需整体反序列化再写回） | 支持（HINCRBY、HSET 单个 field） | 不支持 |
| 过期管理 | 键级 TTL，原生支持 | 键级 TTL，原生支持 | 键级 TTL，原生支持 |
| 内存效率 | 中等（JSON 序列化后存储） | 高（字段级存储，避免序列化开销） | 低（每个元素独立存储，元数据开销大） |
| 集合操作 | 不支持 | 不支持 | 支持并集、交集、差集 |
| 典型场景 | 简单令牌、一次性 token | 多字段令牌、需部分更新 | 用户令牌列表、批量撤销 |
3.3 String 结构：适用于简单令牌与一次性 Token
String 是 Redis 最基础的结构，将整个令牌信息序列化为 JSON 字符串后存储。其优势在于实现简单、查询性能极高，适合以下场景：
- 一次性令牌：如 OAuth2 的 authorization_code，使用后立即删除，无需维护多个字段。
- 简单 access_token：仅需存储用户ID和过期时间，字段极少，序列化开销可忽略。
- 临时缓存：如验证码、短时效的 refresh_token，TTL 很短（秒级），不需要复杂操作。
注意：当令牌字段超过 3 个时，String 的序列化/反序列化开销会显著增加。每次更新任意字段都需要读取整个 JSON、修改、再写回，在高并发刷新场景下容易产生竞态条件。
典型存储示例：
SET access_token:abc123 '{"uid":1001,"role":"admin","exp":1700000000}' EX 36003.4 Hash 结构：多字段令牌的首选
Hash 将令牌的各个属性存储为独立的 field-value，无需序列化整个对象。这是认证授权平台中最推荐的令牌存储结构，原因如下：
- 部分更新高效：刷新令牌时只需更新 exp 或 refresh_count 等单个 field，无需读取整个对象。
- 内存利用率高：当字段数量较少（通常 5~10 个）时，Hash 的编码方式（ziplist）比 String 更节省内存。
- 字段可扩展：新增字段（如添加 scope、client_id）不影响已有数据，无需修改序列化协议。
典型存储示例：
HSET token:refresh:xyz123 uid 1001 role admin exp 1700000000 client_id web_app
EXPIRE token:refresh:xyz123 86400
性能数据：在 1000 QPS 的令牌刷新压力下，Hash 结构的平均延迟比 String 低 15%~20%，主要原因是避免了 JSON 序列化/反序列化。
3.5 Set 结构：用户令牌集合与批量撤销
Set 不适合作为令牌的“主存储”，但在令牌管理的辅助场景中不可或缺：
- 用户活跃令牌列表：使用 Set 记录某个用户的所有活跃 refresh_token，便于用户主动撤销全部令牌时一次性删除。
- 黑名单/白名单：将已撤销的令牌 JTI（JWT ID）加入 Set，查询时快速判断令牌是否有效。
- 去重统计：统计某个客户端或用户的令牌数量，Set 的 SCARD 命令可直接返回基数。
典型存储示例：
SADD user:tokens:1001 refresh_token:xyz123 refresh_token:abc456
SREM user:tokens:1001 refresh_token:xyz123
SMEMBERS user:tokens:1001 // 获取用户所有活跃令牌
组合使用：Hash 存储令牌详情，Set 维护用户与令牌的映射关系。撤销用户所有令牌时，先 SMEMBERS 获取令牌列表，再 DEL 每个 Hash 键，最后 DEL Set 键。
3.6 数据结构选型决策流程
下图展示了在令牌刷新接口中，如何根据具体需求选择 Redis 数据结构：
3.7 组合使用的最佳实践
在实际的认证授权平台中，单一数据结构往往无法满足所有需求。推荐采用 Hash + Set 组合模式：
- Hash 存储令牌详情：以
token:refresh:{token_id}为键，存储 uid、role、exp、client_id、scope 等字段。 - Set 维护用户映射：以
user:tokens:{uid}为键，存储该用户所有活跃的 refresh_token ID。 - 原子化刷新操作：使用 Lua 脚本或 Redis 事务，同时更新 Hash 中的 exp 字段和 Set 中的令牌列表。
组合优势：Hash 保证单点查询性能，Set 提供集合操作能力。两者通过 token_id 关联，互不干扰。内存开销仅增加一个 Set 键，远低于将令牌信息冗余存储多份。
3.8 选型避坑清单
| 常见错误 | 后果 | 正确做法 |
|---|---|---|
| 所有令牌都用 String 存储 | 部分更新需反序列化，高并发下竞态条件导致数据不一致 | 字段超过 3 个时改用 Hash |
| 用 Set 存储令牌详情 | 无法按 token_id 单点查询，需遍历整个集合 | Set 只存索引，详情用 Hash |
| Hash 字段过多（超过 50 个） | ziplist 转换为 hashtable，内存效率下降 | 拆分多个 Hash 或使用 JSON 序列化 |
| 忽略 Set 的元数据开销 | 大量用户令牌列表占用过多内存 | 设置 Set 的 TTL，定期清理过期令牌 |
总结：在令牌刷新接口中，Hash 是主力存储结构，String 适用于极简场景，Set 作为辅助索引。三者各司其职，组合使用才能构建高性能、可维护的令牌缓存层。