Redis Cluster分片故障时会如何运行，锁会受什么影响？

Redis Cluster的运行策略和分布式锁的最终表现，取决于集群的具体配置，分两种常见情况：

Redis Cluster默认要求所有16384个哈希槽都有可用节点负责，对应核心配置项为cluster-require-full-coverage，默认值为yes。

• 采用默认配置（cluster-require-full-coverage=yes）
  当单个分片的主、副本节点同时宕机时，该分片负责的哈希槽完全不可用，整个集群会直接进入FAIL状态，拒绝所有读写请求，自然也不会处理新的锁申请，直到故障分片恢复、对应哈希槽重新被正常节点承接才会恢复服务。这种场景下不会出现剩余分片单独运行创建新锁的情况，但原本故障分片上已持有的锁也会随节点宕机丢失。

• 配置为cluster-require-full-coverage=no
  该配置下集群会容忍部分哈希槽不可用，仅用剩余正常的分片对外提供服务。此时新的锁申请如果对应的哈希槽落在正常分片的负责范围内，集群会正常处理并创建锁；如果哈希槽落在故障分片范围内才会返回错误。这种模式存在锁安全风险：如果故障分片恢复后，原有未过期的旧锁还存在，就可能出现两个客户端同时持有同一逻辑锁的问题。

如果你的分布式锁是基于Redlock算法实现，3分片集群只要2个分片可用就满足多数派要求，算法本身会允许在剩余分片上创建新锁，同样会存在上述安全隐患。

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