Redis JSON 和 Hash 存储对象有什么区别

在 Redis 里保存一个用户、商品或配置对象时，Hash 和 JSON 都能完成“一个 key 对应一组数据”，但它们解决的不是同一类问题。先给结论：对象是扁平字段、经常按字段单独读写时优先 Hash；对象包含嵌套结构、数组，或者业务需要按路径修改和查询时优先 JSON。JSON 的建模能力更强，但通常也要接受比 Hash 更高的内存与处理开销。

官方资料：https://redis.io/docs/latest/develop/data-types/

下面用同一个用户对象对照两种方案，再从更新粒度、查询能力和生产资源边界做一次选择。示例命令是说明用法，不代表某个本机执行结果。

先看对象的形状：平面字段还是嵌套文档

Hash 的核心模型是一个 key 下挂多个 field-value 对，字段值按字符串处理，适合姓名、状态、等级、城市这类平面属性。JSON 则保存符合 JSON 格式的对象、数组和嵌套值，可以用路径定位到对象中的一部分。

# Hash：把对象拆成平面字段，适合独立读取和修改
redis-cli HSET user:42 name "林海" age 31 city "杭州"
# 只读取城市字段，不需要取回整个对象
redis-cli HGET user:42 city

# JSON：保留 profile 和 addresses 的层级关系；$ 表示根路径
redis-cli JSON.SET user:42 $ '{"name":"林海","profile":{"level":3},"addresses":[{"city":"杭州"}]}'
# 只读取 profile.level 这条嵌套路径
redis-cli JSON.GET user:42 '$.profile.level'

这里的分界很重要：Hash 可以把 JSON 字符串塞进某个 field，但那只是“把文档当字符串存放”，Redis 并不知道字符串内部的 profile 或数组，也就不能像 JSON 那样直接按内部路径操作。反过来，如果对象永远只有少量平面字段，直接上 JSON 也会把简单问题带进更复杂的文档模型。

读写粒度决定代码会不会变重

Hash 的常用命令语义直观：HSET 写一个或多个 field，HGET 读一个 field，HMGET 读多个 field，HINCRBY 还能对整数型字段做递增。更新昵称时只改 name，不会触碰同一个 key 下的其他字段。

JSON 的优势是把更新粒度推进到文档内部。比如只调整等级，可以直接写入 $.profile.level；数组也有专门的追加、插入和弹出命令。这个能力更贴近领域对象，但也意味着客户端、服务端命令和部署环境都要支持 JSON 命令。

# Hash：单字段更新，命令和字段边界都很明确
redis-cli HSET user:42 city "宁波"
# 计数类字段可以使用 Hash 的整数递增命令
redis-cli HINCRBY user:42 login_count 1

# JSON：只改嵌套字段，不必重新拼接整个文档
redis-cli JSON.SET user:42 '$.profile.level' 4
# JSON 数组追加一个地址对象；路径必须指向数组
redis-cli JSON.ARRAPPEND user:42 '$.addresses' '{"city":"宁波"}'

如果多个服务只关心对象的不同平面字段，Hash 的字段级并发更新通常更容易约定；如果一个业务动作天然要维护嵌套对象的一致形状，JSON 能减少应用层反序列化、修改、再序列化的样板代码。无论选哪种，都要先写清字段归属，避免一部分代码把同一个 key 当 Hash，另一部分代码又把它当 JSON。

查询能力和资源成本要一起看

Hash 适合按已知 field 读取。需要筛选嵌套属性、数组元素或对文档做更灵活的索引查询时，JSON 更合适；Redis 官方文档也把 JSON 描述为支持层级数组、对象和路径访问，并指出它与 Redis Search 的结构化查询能力结合得更强。

但“查询更灵活”不是免费能力。官方比较资料给出的方向是：文档数据通常是 JSON 的内存和处理要求最高，其次是 Hash，再到字符串。这里不应把它理解为任何场景下的固定基准，而应当理解为选型提醒：缓存数量大、对象扁平、只按字段取值时，Hash 更容易守住资源预算；对象复杂且查询需求真实存在时，JSON 的额外成本才有明确回报。

上线前把选择落成几条规则

第一，先确认部署实例是否提供 JSON 命令，再决定是否把 JSON 当作统一存储格式。第二，为 key 写出稳定的对象边界，例如 user:{id} 只代表一个用户，不要让同一 key 在不同版本中随意改变数据类型。第三，给 Hash 的 field 和 JSON 的路径都建立命名约定，尤其是数组内部字段，避免客户端各写一套路径。

第四，TTL 仍然作用于 key，而不是天然作用于对象内部的每个字段；如果某个子字段必须独立过期，就把它拆成独立 key，或在应用层维护过期信息。第五，迁移时不要只比较命令数量，要同时盘点读写客户端、索引需求、内存预算和回滚方式。可以先新增一组版本化 key，在读路径兼容一段时间，再切换写路径。

# 先查看 key 的数据类型，避免用错命令
redis-cli TYPE user:42
# 迁移前同时记录 TTL，防止新旧 key 的过期策略不一致
redis-cli TTL user:42
# 只在确认 JSON 能力和路径约定后，再修改嵌套字段
redis-cli JSON.SET user:42 '$.profile.level' 4

可以把最终判断压缩成一句话：对象像数据库表里一行的几个简单列，就从 Hash 开始；对象本身就是需要局部访问的文档，就选 JSON；如果两者都能满足需求，优先选择团队更熟、资源预算更容易解释的那一个。

常见问题

Hash 能不能保存嵌套对象？

可以把嵌套 JSON 序列化成某个 field 的字符串，但 Redis 只能把它当字符串读写，不能直接理解内部路径。需要路径级访问时，应使用 JSON 或拆成独立 key。

JSON 一定比 Hash 查询更快吗？

不能这样下结论。JSON 的能力范围更大，但官方资料明确提醒它通常有更高的内存和处理要求。速度要结合数据形状、命令、访问模式和实际资源预算判断，不能只看数据类型名称。

用户资料应该默认用哪一种？

只有姓名、状态、等级等平面字段时，Hash 往往更简单；如果资料包含地址数组、偏好设置等层级数据，并且业务需要单独修改这些内部节点，JSON 更自然。先画出对象结构，再决定比“用户资料”这个名词更可靠。