Comparison
Distributed lockvsFencing token
Distributed lock
you need only one instance across the whole fleet to run the job, so they all try to claim a key in Redis first.
Mutual exclusion coordinated through an external store shared by multiple processes. It is far weaker than an in-process lock: the holder can be paused, partitioned or garbage-collected while its lease expires, and it will not know. Safe use needs a lease plus a fencing token checked by the resource itself.
Full entry →Fencing token
the old leader wakes up from a long pause still believing it holds the lock, and the storage layer rejects its write because its number is stale.
A monotonically increasing number handed out with a lock or lease, which the resource checks and refuses if it has already seen a higher one. It is what makes distributed locking actually safe, because a process can be paused arbitrarily long by GC or scheduling and wake with an expired lease it does not know is expired. Without fencing, a distributed lock is a strong suggestion.
Full entry →