存储桌游会话数据时，RedisJSON 比原生 Redis 更合适吗？

原生Redis哈希+多结构组合方案 #

适用场景 #

• 用户对象字段少于10个、嵌套层级浅（最多1层数组）的轻量化场景
• 服务端资源有限，不想额外安装、维护Redis第三方模块的场景
• 单字段操作频率远高于全对象读取的场景，比如仅频繁更新用户的游戏分数、在线状态
• 需要兼容旧版Redis、或云服务商Redis实例不支持自定义模块的场景

缺陷 #

• 数组类型无法直接存储，需要单独命名user:{id}:xxx_arr的键用List/Set存储，读取全量用户数据需要发起多次Redis请求，或用MGET/流水线打包请求，增加了代码复杂度
• 字段值只能存储字符串，数字类型存取时需要手动做类型转换，容易出现隐式类型转换的bug
• 后续如果对象字段增加、嵌套层级变深，维护成本会线性上升，比如要存储用户的装备数组、且每个装备还有独立属性时，就要新增更多独立Key

RedisJSON方案 #

适用场景 #

• 你当前的场景就非常适配：单用户对象不复杂、但存在数组类型字段，全量读取对象的频率高
• 多人桌游场景下经常需要拉取完整的用户状态同步给客户端，单次请求就能拿到完整JSON结构，无需自行做数据聚合，代码逻辑非常简洁
• 后续有字段扩展需求，比如要新增嵌套的游戏状态、背包数据，不需要调整存储结构，直接修改JSON结构即可
• 需要对嵌套字段做查询、修改时，RedisJSON支持直接操作JSON路径，比如直接给用户的某件装备增加属性，不需要读取全量数据再写回

缺陷 #

• 需要额外安装RedisJSON模块，如果你使用的是云托管Redis，要提前确认服务商是否支持该模块
• 内存占用比原生哈希高15%~30%左右，不过你的单对象字段少，这个差距基本可以忽略
• 部分Redis客户端对RedisJSON的命令封装没有原生命令完善，ioredis本身是支持的，但调用时要写对应的JSON命令，比原生哈希的HGET/HSET写法稍微复杂一点

多人桌游WebSocket场景建议 #

直接选用RedisJSON即可。桌游场景下你大概率要频繁把全量用户状态推送给同一个房间的其他玩家，单次拉取完整JSON的效率远高于自行聚合多个Key的数据，而且数组类型可以直接存储无需额外处理，能节省大量胶水代码。如果后续需要做增量更新，RedisJSON也支持直接修改单个嵌套字段，完全满足需求。

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