Safe distributed lock redesign

Your team currently uses single-instance Redis SETNX-with-TTL as a distributed lock and has hit incidents where two workers both believed they held the lock. Design a safer locking scheme for the same use case — serializing ~2k/sec short critical sections — and decide whether a quorum scheme (Redlock across 5 independent nodes) actually fixes the root cause. Constraints: low latency, tolerate single-node Redis failure, and provably prevent two simultaneous holders for the protected operation. Describe the mechanism and justify your choice.