服务端刷新令牌管理方案选型：Redis与MySQL存储对比

现有方案优劣分析 #

1. Redis键值对方案（userId_accessToken:refreshToken） #

优点：

• 性能优异：Redis读写延迟极低，完全能支撑高频令牌校验、更新场景，适配认证类高并发需求
• 运维成本低：自带TTL过期机制，无需额外维护定时任务，过期令牌自动清理
• 内存充足：服务器内存约3.8G，按每条令牌键值对占用100字节估算，可存储近4000万条记录，完全满足中小规模业务的多设备登录需求

缺点：

• 令牌变更时需执行DEL+SET操作，但二者均为Redis原子操作，只要业务逻辑中先删除旧键再插入新键，不会出现一致性问题，实际业务风险极低

2. MySQL（RDS）存储方案 #

优点：

• 数据持久化可靠：适合需要留存令牌审计记录的场景，方便事后排查登录日志
• 支持复杂查询：可快速统计某用户的所有登录设备、批量吊销该用户的所有令牌

缺点：

• 性能瓶颈明显：令牌校验属于高频操作，MySQL读写性能远低于Redis，用户量上升后易拖慢接口响应速度
• 运维复杂度高：需维护定时任务清理过期记录，即使使用RDS事件调度器替代cron，也需考虑清理时的锁表风险，影响业务稳定性
• 存储开销大：每条记录需存储id、userId、多令牌字段、过期时间，相比Redis键值对，磁盘与内存占用均更高

方案选型建议 #

• 若核心需求是低延迟、高并发的令牌校验，优先选择Redis方案：内存充足，自带TTL省去运维麻烦，DEL+SET的操作成本可忽略
• 若有强审计或复杂查询需求，可采用MySQL+Redis缓存组合：令牌校验先查Redis，不存在时再查MySQL并同步至Redis（同时设置TTL），平衡性能与持久化需求

其他推荐方案 #

Redis Hash结构存储 #

无需拆分键，以user:{userId}:tokens作为Hash键，将accessToken设为Hash的field、refreshToken设为value，给整个Hash设置统一TTL（或定期清理过期令牌）：

• 优势：批量管理用户令牌更便捷，例如吊销用户所有设备直接执行DEL user:{userId}:tokens，查询所有登录设备使用HGETALL user:{userId}:tokens
• 注意：Redis暂不支持单独给Hash的field设置TTL，需在业务层统一控制过期时间，或定期扫描清理过期field

Redis Set+Hash组合 #

• 用Setuser:{userId}:active_access_tokens存储用户的所有有效accessToken
• 用Hashaccess_token_map存储accessToken到refreshToken的映射，给每个Hash键单独设置TTL
• 优势：可快速判断accessToken是否有效（SISMEMBER命令），同时支持单独管理每个令牌的过期时间
• 不足：多了一层Set的维护逻辑，业务复杂度略有提升

成熟认证中间件 #

若不想重复造轮子，可直接使用Keycloak、Authing等开源/商业认证服务，这类工具内置多设备登录、令牌生命周期管理、过期清理等功能，开箱即用，节省开发成本

内容的提问来源于stack exchange，提问作者user10874312