4、Token存储方案设计：Redis作为Token存储的选型理由、Key设计规范与Value序列化方式

在分布式鉴权拦截场景中，Token（如JWT、Opaque Token、Session ID）的存储方案直接决定了系统的吞吐量、可用性与安全性。本章从选型理由、Key设计规范、Value序列化三个维度，给出可落地的Redis存储方案。

4.1 为什么选择Redis作为Token存储

Token存储需要满足：高并发读写、自动过期、数据一致性、低延迟。Redis的以下特性使其成为首选：

4.2 Key设计规范：命名空间与过期时间

Key设计直接影响查询效率、运维可读性以及避免冲突。以下规范已在生产环境验证：

4.2.1 命名空间结构

采用冒号分隔的多级命名空间，格式为：

项目:业务域:环境:Token类型:用户标识:随机后缀

实际示例：

auth:token:prod:jwt:uid_10086:a3f2b1
auth:refresh:prod:opaque:sid_9527:c8d9e0
auth:blacklist:prod:jwt:jti_abc123

4.2.2 过期时间（TTL）设计

TTL必须与Token本身的有效期对齐，并预留缓冲窗口：

// Java示例：设置TTL
String key = "auth:token:prod:jwt:uid_10086:a3f2b1";
long ttlSeconds = 900 + 30; // 15分钟 + 30秒缓冲
redisTemplate.opsForValue().set(key, tokenValue, ttlSeconds, TimeUnit.SECONDS);

4.3 Value序列化方式：JSON vs Protobuf

Token的Value通常包含用户基本信息、权限列表、设备指纹等元数据。序列化方式直接影响内存占用和反序列化性能。

4.3.1 序列化对比

4.3.2 生产推荐策略

• 中小规模（单节点 < 500万Token）：使用JSON序列化，配合压缩（如Snappy或LZ4），可读性与性能平衡。
• 大规模（集群 > 1000万Token）：强制使用Protobuf，内存节省60%以上，反序列化延迟降低40%。
• 混合策略：Redis中存储Protobuf二进制，同时保留JSON日志用于审计和调试。

// Protobuf定义示例（token.proto）
syntax = "proto3";
package auth;

message TokenValue {
  string user_id = 1;
  string username = 2;
  repeated string roles = 3;
  int64 expire_at = 4;
  string device_fingerprint = 5;
  map<string, string> extensions = 6;
}

// Java序列化代码
TokenValue token = TokenValue.newBuilder()
    .setUserId("10086")
    .setUsername("alice")
    .addRoles("admin")
    .addRoles("editor")
    .setExpireAt(System.currentTimeMillis() + 900000)
    .build();
byte[] data = token.toByteArray();
redisTemplate.opsForValue().set(key, data, ttlSeconds, TimeUnit.SECONDS);

4.4 Token存储整体架构图

下图展示了Token从生成到存储、鉴权、刷新的完整数据流：

4.5 序列化方式选择决策树

根据实际业务场景，可参考以下决策流程：

4.6 生产落地检查清单

• Key命名：统一使用小写字母、数字、冒号，禁止使用空格、中文、特殊字符。
• TTL设置：所有Token Key必须设置TTL，禁止永不过期；黑名单Key的TTL与原Token剩余有效期一致。
• Value大小：单条Value建议控制在2KB以内；超过2KB考虑拆分或使用Hash结构。
• 序列化选型：Protobuf的Schema文件纳入Git版本管理，每次变更需评审兼容性。
• 监控告警：监控Redis内存使用率、Key数量、平均TTL、OOM风险；设置内存使用率超过80%的告警。
• 定期清理：即使有TTL，也建议每日扫描过期Key占比，确保主动过期机制正常工作。