Redis中HSCAN与HVALS的性能对比及适用场景选型咨询

核心性能差异 #

直接针对你15万键值对的哈希场景给出对比结论：

• HVALS 是单条原子命令，总执行耗时更低，但会阻塞Redis单线程：15万条数据的读取+序列化返回过程，会占用Redis实例数毫秒到数十毫秒的处理时间，期间所有其他请求都会排队等待，高并发场景下很容易触发大面积请求超时。同时单条返回的数据包体积大，会占用更多网络带宽，NodeJS端一次性解析全量数据也会导致事件循环短暂阻塞、内存占用突增。
• HSCAN 是分片遍历命令，总执行耗时略高于HVALS（多了9次左右的RTT开销，按单次RTT 1ms算也只会多不到10ms），但不会长时间阻塞Redis线程：每次仅返回1.5万条数据，单次处理耗时不足1ms，不会影响其他请求的正常执行。NodeJS端可以边遍历边处理数据，内存占用平缓，不会出现尖峰。

你的场景选型建议 #

生产环境在线业务优先选node-redis-scan的eachScan()方案：10次左右的请求开销极低，几乎可以忽略，同时能规避HVALS的阻塞风险，稳定性高。
只有当你的场景满足以下所有条件时，才适合选hvals()方案：

1. 任务在低峰期执行，Redis无其他高优先级请求
2. 业务对全量数据的一致性要求极高，需要拿到某一时刻的完整快照（HSCAN遍历过程中如果有数据修改，可能出现重复返回或遗漏修改后数据的情况）
3. NodeJS端内存充足，能承受一次性加载全量15万条数据的开销

二者通用适用场景 #

HVALS适用场景 #

• 单哈希的键值对数量规模小（建议小于1万条）
• 离线批量任务、低峰期运维脚本等对Redis阻塞容忍度高的场景
• 需要获取哈希全量数据的强一致性快照的场景

HSCAN适用场景 #

• 单哈希键值对规模超过1万条的生产环境在线业务
• 对Redis服务稳定性要求高，不能接受长时间单命令阻塞
• NodeJS端需要流式处理数据，避免一次性加载全量数据导致内存溢出
• 需要对哈希键做模糊匹配过滤的场景（可直接用MATCH参数在Redis端过滤，减少无效数据传输）

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