Redis按Key分区场景下为何还需要使用分布式锁

首先明确结论：你对Redis哈希分区的理解是正确的，常规场景下不需要用到跨多节点的分布式锁，Redlock算法的设计目标和你当前理解的单key锁场景并不重合。

1. 常规业务场景的锁实现逻辑完全符合你的判断 #

常规Redis哈希分区规则下，单条KV数据确实只会存储在一个指定的分片主节点中：

• 针对交易id为123的记录，你只需要用规则生成对应的锁key（比如lock:trade:123）
• 该锁key会通过哈希规则定位到对应分片节点，直接用SET key random_value NX EX 过期时间命令即可完成加锁
• 这种实现逻辑没有任何问题，90%以上的业务分布式锁场景都可以用这种方式满足。

2. 跨多节点的Redlock算法解决的是单点故障风险 #

你所疑惑的跨N个节点加锁的逻辑，本质是为了规避单节点故障引发的锁失效问题：
假设你在0号节点加锁成功后，0号节点立刻宕机，且锁数据还没同步到从节点，此时从节点升级为新主节点，该节点上不存在你刚刚加的锁记录，其他客户端申请同一锁就会成功，进而出现两个客户端同时持有锁的安全问题。
Redlock的设计就是为了尽可能降低这种风险：它要求你在N个相互独立的Redis主节点（这些节点并非业务分片集群的节点，是专门用于锁服务的独立实例）上同时申请锁，只有超过半数节点加锁成功才算持有锁，释放锁时也需要在所有节点执行释放操作。这种设计下只要故障节点不超过半数，锁的安全性就能得到保障。

3. 什么时候不需要用Redlock？ #

如果你的业务场景能接受极小概率的锁失效风险，或者对锁的安全性要求没有达到金融级、支付级的程度，完全不需要引入Redlock的复杂逻辑，单分片节点加锁已经足够使用。

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