选用HSETNX而非SETNX，因其支持字段级原子占位与业务维度隔离，可在同一Hash key下高效管理多业务围栏，避免key冲突、提升复用率且内存友好。
用 Redis Hash 配合 HSETNX（注意：不是 Hsetns，正确命令是 HSETNX）构建防重入围栏，核心在于“字段级原子占位 + 业务语义隔离”，而非全局锁。它轻量、高效，特别适合同一业务实体下的多次操作互斥（如一个用户对同一订单的重复提交、一个商品ID的多次秒杀请求），但不适用于跨实体强一致场景。
为什么选 HSETNX 而不是 SETNX？
HSETNX 是 Hash 类型的“字段存在性写入”命令，只在指定 field 不存在时才设置成功，返回 1；已存在则失败，返回 0。相比字符串类型的 SETNX：
- 它天然支持按业务维度（如 order_id、user_id、sku_id）组织围栏，避免 key 冲突或误删
- 同一个 Hash key 下可并行管理多个 field（例如 user:1001 下设 submit_order_123、cancel_order_456 等），复用率高、内存友好
- 无需拼接复杂 key 名，降低运维和排查成本
典型安全围栏设计模式
以“用户提交订单防重”为例，步骤如下：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
定义 Hash key：如
guard:user:1001（按用户隔离，也可用guard:order:123按订单隔离） -
定义 field：用带业务标识的唯一字段名，如
submit:order_123:ts_1747673400或更简洁的submit:123 -
执行 HSETNX：
HSETNX guard:user:1001 "submit:123" "1" - 判断结果：返回 1 → 成功占位，允许后续业务逻辑；返回 0 → 已存在，直接拒绝，返回“重复提交”
-
配套清理（可选）：若需自动过期，不能直接给 field 设 TTL（Hash 的 field 不支持单独过期），可用以下任一方式：
- 为整个 Hash key 设置过期：
EXPIRE guard:user:1001 300（5分钟） - 业务侧异步清理：成功处理后调用
HDEL guard:user:1001 submit:123 - 结合时间戳字段：field 值存当前毫秒时间，读取时校验是否超时（需额外
HGET+ 逻辑判断）
- 为整个 Hash key 设置过期：
关键注意事项与避坑点
这个方案看似简单，但几个细节决定成败：
- field 必须具备唯一性和业务含义：不能用随机 UUID 作 field，否则无法识别“谁占了哪个围栏”。推荐组合形式：动作类型 + 业务主键 + （可选）上下文标识
- 不适用于长事务或阻塞等待：HSETNX 是纯判断，不提供“等待锁释放”能力。如需重试，由客户端控制（例如失败后 sleep 50ms 再试，最多 3 次）
-
慎用 HGETALL/HKEYS 做状态扫描：Hash 字段数多时，这些命令会阻塞 Redis 单线程。如需监控围栏占用情况，改用
HSCAN渐进式遍历 - 不要混淆 HSETNX 和 HSET：HSET 会覆盖已有值，失去“首次占位”语义；HSETNX 才是真正的“仅当不存在时设置”
- 注意 Hash 内部编码优化：当字段数
对比分布式锁的适用边界
HSETNX 围栏 ≠ Redisson 分布式锁，二者定位不同：
- 围栏（HSETNX）：解决“同一业务单元的重复操作”，强调幂等性，无等待、无续期、无死锁风险，开销极低
- 分布式锁（如 Redisson）：解决“跨节点对共享资源的排他访问”，强调临界区保护，需自动续期、看门狗、可重入等机制，适合扣库存、生成唯一流水号等强一致性场景
一句话总结：要防“自己重复点两次”，用 HSETNX 围栏；要防“大家同时改同一个库存”，用专业分布式锁。
