Redis如何存储用户个人资料_利用Hash结构实现字段级别的更新

张开发
• 2026/4/12 18:37:04 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

Redis如何存储用户个人资料_利用Hash结构实现字段级别的更新
应使用HSET分字段存储用户资料而非SET存JSON因其支持原子性单字段操作、避免并发覆盖、节省带宽字段名须全小写下划线慎用HGETALL防性能陷阱Hash无内置TTL需显式EXPIRE。用 HSET 存字段别用 SET 存整个 JSON直接把用户资料序列化成 JSON 用 SET 存看似简单但改头像、改昵称就得反序列化→修改→再序列化→重写整条记录。不仅浪费带宽还可能在并发时丢更新比如两个请求同时读旧 JSON、各自改一个字段、再写回去其中一个改动就没了。HSET 把每个字段当独立子项存进 Hash天然支持单字段增删改查HSET user:10086 nickname 阿哲 avatar_url /avatars/10086.png age 28只改昵称HSET user:10086 nickname 阿哲2号其他字段完全不动新增字段直接加比如 HSET user:10086 bio 前端搬砖人字段不存在自动创建已存在原地覆盖原子性有保障字段名别带空格或特殊符号统一小写下划线Redis 的 Hash 字段名本质是字符串但实际使用中会频繁拼接、校验、日志打印。如果字段名是 user_name 和 userName 混用或者出现 first name带空格后续用 Lua 脚本或客户端批量操作时容易出错排查起来也费劲。推荐命名nickname、email_verified、last_login_at避免Nick Name、userEmail驼峰和下划线混用、created-at连字符在某些客户端解析异常所有字段名全小写下划线和数据库字段习惯对齐也方便 ORM 或中间层映射注意 HGETALL 的性能陷阱大 Hash 别随便全量拉用户资料字段少时HGETALL user:10086 拿全部字段没问题。但如果后期加了 settings_json、notification_prefs 这类长文本字段Hash 可能膨胀到几 KB甚至上百 KB。每次 HGETALL 都要序列化全部字段、网络传输、客户端解析——延迟陡增还浪费内存。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。

更多文章