Redis中用户及用户会话的HKEY存储方案与相关技术疑问

场景背景 #

现有200万用户的Users表（存储密码、角色、配置文件ID等），500万未过期会话的User_sessions表（存储user_id、session_id、过期日期、user_role等），计划在4-8GB内存的Redis中存储相关数据，当前初步方案为：Users表存PostgreSQL，会话数据存Redis，会话键采用16-64字节随机UID。

问题1：Redis默认配置下，会话存Hash是否可行？Hash键重复的应对策略？ #

Redis的Hash结构不存在全局重复键限制：Hash的字段（field）仅在同一个Hash对象内不能重复，而Redis全局键（key）本身要求唯一，因此用Hash存储会话完全可行，甚至是优化内存的优质方案。

推荐策略：

• 单会话独立Hash：以session_id作为Redis全局键，每个会话对应一个独立Hash对象，Hash内存储user_id、expire_date、user_role等字段。这种方式逻辑简单，不会出现字段重复问题，还能通过EXPIRE命令为每个会话键设置过期时间，自动清理失效会话，500万会话的内存占用预估在300-500MB，远低于4-8GB的内存上限。
• 哈希分片（可选优化）：若想进一步压缩内存，可按user_id哈希值分片，将同分片内的多个会话存入同一个Hash，用session_id作为Hash字段，会话数据序列化后作为值。但需注意控制分片粒度，避免单个Hash过大；同时因Redis无法为Hash单个字段设置过期，该方式仅适合会话过期时间相近的场景。

问题2：是否需要将User表存储到Redis中？ #

无需全量存储，建议采用热数据缓存策略：

• 200万条用户数据全量缓存会占用约200MB内存（按单条100字节估算），虽在内存上限内，但用户数据更新频率低却需维护缓存一致性，增加不必要的复杂度。
• 仅缓存高频访问的活跃用户数据：比如最近7天登录过的用户的角色、配置文件ID等常用字段，用user_id作为Redis键存储为Hash或字符串；非活跃用户直接从PostgreSQL查询即可，既降低Redis内存占用，又减少缓存一致性维护成本。
• 注意：密码绝对不能存入Redis，必须加密后存在PostgreSQL中，避免内存泄露风险。

问题3：高频小量权限查询（<1000条无关联数据），选Redis还是PostgreSQL？是否值得切换？ #

建议切换到Redis，核心理由：

• 性能差距明显：Redis内存查询延迟在微秒级，PostgreSQL磁盘查询（即使有缓存）延迟在毫秒级，对于每次请求都需调用的权限查询，Redis能显著降低接口响应时间，提升系统吞吐量。
• 内存可忽略：权限数据量小于1000条，按单条100字节计算仅占用约100KB内存，几乎不消耗Redis资源。
• 维护成本低：权限数据更新频率低，更新时只需同步刷新Redis缓存即可，逻辑简单。
• 无论当前PostgreSQL查询是否存在性能瓶颈，切换都能为未来流量增长预留性能空间；若已出现CPU占用高、查询延迟大的情况，切换收益会非常直观。

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