在分布式系统里，用户登录以后服务器不能再依赖单机内存里的Session，把登录状态Token放到Redis集中管理成了主流做法。Redis基于内存、支持过期淘汰、提供多种数据结构，非常适合承担令牌的写入、校验与注销。但很多团队在落地时只用了最基础的String存Token，导致无法支持多端登录、无法主动让Token失效、刷新逻辑混乱。本章先给出整体设计思路，后续从存储结构、注销与刷新、安全与性能三个角度展开。
一、Redis中Token的存储结构选型
最直白的方式是用String类型，key为token:<token值>，value存用户ID，并设置过期时间。这种方案实现简单，校验时只需GET一次就能拿到用户身份，配合EXPIRE自动清理。但在需要记录登录设备、IP、签发时间等元数据时，就要反复存多个key，或者把value序列化成JSON，既浪费空间也不方便部分更新。
更合理的做法是使用Hash结构，key为user:token:<userId>:<tokenId>，field包括user_id、device、ip、expire_at等。这样可以在不读取整个对象的情况下用HGET取单个字段，也能用HSET更新登录IP。对于同一个用户的多端登录，可以再用一个Set结构，key为user:sessions:<userId>，成员为各个tokenId，踢下线时直接SREM再删Hash即可。
下面给出Hash加Set的组合示例代码，使用Java的Jedis客户端：
// 存储Token元数据并记录到用户会话集合
String tokenKey = "user:token:" + userId + ":" + tokenId;
Map<String, String> map = new HashMap<>();
map.put("user_id", userId);
map.put("device", "web");
map.put("ip", "192.168.0.1");
map.put("expire_at", String.valueOf(System.currentTimeMillis() + 7200000));
jedis.hset(tokenKey, map);
jedis.expire(tokenKey, 7200);
jedis.sadd("user:sessions:" + userId, tokenId);
// 校验Token是否存在且未过期
String sessionKey = "user:sessions:" + userId;
if (jedis.sismember(sessionKey, tokenId) && jedis.exists(tokenKey)) {
String uid = jedis.hget(tokenKey, "user_id");
// 校验通过
}
二、Token注销与自动刷新机制
只靠Redis的过期时间，用户点击退出时Token还会存活一段时间，存在安全风险。主动注销要求后端在退出接口里删除对应的Hash和Set成员，让后续校验直接失败。如果用了JWT这类无状态Token，由于本身无法撤销，就必须把JWT的jti写进Redis黑名单，校验时先查黑名单再验签名，这就是典型的双写模式。
关于刷新，常见误区是每次请求都重新设置过期时间，这会让长期活跃用户Token永远不过期，给盗用者可乘之机。正确做法是采用滑动窗口：只有距过期小于阈值（如半小时）时才延长，或者另发一个refresh_token，访问令牌短时效、刷新令牌长时效且同样存Redis。刷新时校验refresh_token合法性，签发新access_token并绑定原会话集合。
以下代码展示退出登录时的主动清理逻辑：
import redis
r = redis.Redis(host='127.0.0.1', port=6379, db=0)
def logout(user_id, token_id):
token_key = "user:token:" + user_id + ":" + token_id
session_key = "user:sessions:" + user_id
# 删除令牌元数据
r.delete(token_key)
# 从用户会话集合中移除
r.srem(session_key, token_id)
# 若使用JWT黑名单
r.setex("blacklist:" + token_id, 7200, "1")
三、安全边界与高并发性能考量
把Token放进Redis后，单点故障会让所有用户掉线，因此生产环境至少用主从加哨兵，或者Redis Cluster分片。对于热点用户（如大V账号），其user:sessions被高频访问，可能成为大Key，建议对成员多的Set做拆分，或限制单用户最多登录端数，避免集合无限膨胀。
性能上，校验路径应保持轻量：优先用单次EXISTS或SISMEMBER，避免事务与lua脚本过度使用。遇到缓存击穿，即某个Token刚过期瞬间大量请求打到数据库，可以用互斥锁重建，或给Token续期操作加分布式锁。另外要注意，Redis默认持久化若用RDB，宕机可能丢最近几秒Token，对安全性要求极高时可开启AOF并设为每秒刷盘。
下表对比三种常见存储方案的适用场景：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| String单Key | 实现简单、校验快 | 元数据难扩展、多端弱 | 单体小应用 |
| Hash+Set | 支持多端、可存设备信息 | 键数量多、需双写 | 分布式多端系统 |
| JWT+Redis黑名单 | 无状态、易跨服务 | 注销依赖查黑、存储涨 | 微服务鉴权 |
综合来看，用Redis管理登录Token不是简单套用缓存，而是结合业务登录模型设计键结构与生命周期。从存储选型到注销刷新，再到集群与性能，每一步都直接影响系统的安全与体验。