Scheduled jobs
The same cron runs on every instance, and the lock makes sure exactly one of them does the work.
Core dataCoordination
Distributed Locks
Make sure only one worker runs a job at a time, with locks that expire on their own and are released safely by their owner.
- command to acquire
- 1
- command to release safely
- 1
- Lua scripts
- 0
Step 1 of 5
Worker A takes the lock
NX takes it only if nobody holds it. PX 30000 makes it expire in 30 seconds if A dies.
Example sessionplaying
# Worker A takes the lock
hotkv> SET lock:billing-run tok-a81f NX PX 30000
OK
An animated walkthrough with real HotKV commands and example replies. Click any step to jump to it.
The problem
Cron jobs on several machines, payment captures and cache rebuilds must not run twice at once. A lock without an expiry is held forever when its owner crashes, and releasing a lock with a plain DEL can delete someone else's lock after yours has expired.
How HotKV handles it
SET with NX and PX acquires a lock only if nobody holds it, and gives it an expiry so a crashed owner cannot hold it forever. Each owner stores a random token as the value. DELEX with IFEQ deletes the lock only if it still holds your token, which is the safe release that used to need a Lua script.
Step by step
What happens, command by command
- 01
Worker A takes the lock
NX takes it only if nobody holds it. PX 30000 makes it expire in 30 seconds if A dies.
SET lock:billing-run tok-a81f NX PX 30000 - 02
Worker B is turned away
The lock is held, so B gets nil and skips this run.
SET lock:billing-run tok-b22c NX PX 30000 - 03
A does the work
Only one worker runs the billing job.
PTTL lock:billing-run - 04
Release only your own lock
DELEX deletes the key only if the value is still A's token.
DELEX lock:billing-run IFEQ tok-a81f - 05
A wrong token does nothing
If A had been too slow and B now held the lock, A's release would leave B's lock alone.
DELEX lock:billing-run IFEQ tok-stale
Where it fits
Real-world scenarios
Payments
Capture and refund operations on one order are serialised so they never overlap.
Cache stampede protection
Only one request rebuilds an expensive cache entry while the others wait or serve the stale value.
Built in
What you get
Acquire with expiry
SET NX PX takes the lock only if free, with a timeout.
SETNXPXSafe release
DELEX IFEQ deletes only if the value matches your token.
DELEXExtend while working
Check the remaining time and extend it for long jobs.
PTTLPEXPIRECompare by digest
For large values, DELEX IFDEQ compares a digest instead of the full value.
DIGESTIFDEQCommon questions
Why not just DEL the lock?
If your lock expired and another worker took it, a plain DEL would delete their lock. DELEX IFEQ only deletes it while it still holds your token.
How long should the expiry be?
Longer than the job normally takes. For long jobs, extend the expiry periodically while you still hold the lock.
Do I need Lua for safe release?
No. DELEX does the compare and delete in one command.
Related use cases
Try it on your own workload
HotKV speaks the Redis protocol, so you can point an existing client at it and run these same commands.