特定场景下Redis哈希（Hash）与键模式的性能差异问询

方案一：独立键模式（${customer-id}:${product-id}） #

• 内存开销：每个独立键都会占用Redis的键元数据（如过期时间、类型标识等），当单个客户浏览过的产品数量较多时，会产生大量冗余元数据，内存利用率低。
• 删除操作性能：
  • 若使用KEYS ${customer-id}:*匹配键，该命令会阻塞Redis实例——它会遍历所有键来匹配模式，在键总数较多的场景下，会导致其他请求长时间等待，严重影响服务性能。
  • 若改用SCAN命令分批遍历匹配，虽是非阻塞，但需要多次调用API实现逻辑，代码复杂度高，且整体删除耗时会比单命令操作长。
• 原子性问题：批量删除多个键无法通过单命令完成，中间若出现异常，可能导致部分键未被删除，数据一致性难以保证。

方案二：Hash结构存储 #

• 内存开销：单个Hash键仅存储一份元数据，所有${product-id}作为Hash的field存储，内存利用率远高于独立键模式，尤其是客户产品数据量较大时，内存节省效果明显。
• 删除操作性能：直接通过DEL ${customer-id}命令即可一次性删除该客户的所有产品数据，这是Redis的单原子命令，执行速度极快，不会阻塞实例（即使Hash内部field数量多，DEL的效率也远高于批量删除多个独立键）。
• 查询操作：获取所有产品ID可以用HKEYS ${customer-id}（小数据量）或HSCAN（大数据量非阻塞遍历），操作效率和灵活性都优于方案一的键匹配查询。

总结 #

两种方案的性能差异非常显著：Hash结构在内存效率、删除操作的速度与原子性上都全面碾压独立键模式。独立键模式仅适合单个客户产品数据量极小、Redis总键数极少的极端场景，绝大多数业务场景下都应该优先选择Hash方案。

内容的提问来源于stack exchange，提问作者Marco Antonio Soares Júnior