A counter with a ceiling
The TTL is set on the first write only, so the window does not slide
- operation
- atomic-counter
Redis Lua Script Generator
Pick an operation and get a Lua script that runs it atomically. Two rules decide whether a script survives contact with production: every key goes through KEYS, and the script stays short, because it stops the whole server while it runs.
script.lua
updates as you typeExamples
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
Delete only if unchanged
The comparison and the delete happen with nothing in between
- operation
- compare-and-delete
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Building a key name inside the script
Redis Cluster routes by the keys in KEYS. A key constructed in the body is invisible to routing, so the script works on one instance and breaks when the data is sharded.
Instead:Compute key names in the client and pass them in KEYS.
Expecting a failed script to roll back
Atomic means uninterrupted, not transactional. Commands that already ran stay applied when a later one raises.
Instead:Validate everything before the first write.
Iterating a large collection inside a script
The whole server is stopped for the duration. Once it passes busy-reply-threshold, SCRIPT KILL will not work if the script has written.
Instead:Bound the work, or do it in the client across several calls.
Sending only EVALSHA and never the body
The script cache is in memory and is not replicated. After a restart or a failover every call fails with NOSCRIPT.
Instead:Handle NOSCRIPT by resending the script once.
Getting the key count wrong in EVALSHA
The number after the sha is the key count. Too low and the extra names land in ARGV, so the script reads empty values and does nothing, silently.
Instead:Count the keys, and let the client library do it.
What atomic means here, and what it does not
Lua in Redis gives you one strong guarantee and one that people assume but do not get. The gap between them causes real data problems.
Nothing else runs during a script
Lua executes on the same single thread that serves every client, and it runs to completion with nothing interleaved. That is exactly why a check followed by a write is safe here and is a race when done as two commands from a client.
A script that fails partway is NOT rolled back
Atomic here means uninterrupted, not transactional. If the third command raises an error, the first two have already applied and they stay applied. Redis has no rollback, for scripts or for MULTI. Do every validation before the first write.
Every key must be declared in KEYS
Redis Cluster routes a script by the keys passed in KEYS. A key built inside the script body, or concatenated from ARGV, is invisible to that routing. The script works perfectly on a single instance and breaks the day the data is sharded, which is the worst possible time to discover it.
A long script is an outage
Because nothing else runs, a script that loops over a large collection stalls every other connection. Past busy-reply-threshold the only ways out are SCRIPT KILL, which fails once the script has written, and SHUTDOWN NOSAVE, which loses whatever was not persisted.
EVALSHA fails after a restart or a failover
The script cache is in memory and is not replicated to a promoted replica. A client that only ever sends EVALSHA breaks at exactly the moment of a failover. Every mature client library handles the NOSCRIPT error by resending the body; confirm yours is one of them.
Related redis tools
Redis Config File Generator A redis.conf with the reasons in it Redis ACL Generator A user that can do exactly one job Redis Maxmemory Config Generator The limit, and the headroom it needs Redis Persistence Config Generator How much you can afford to lose Redis TLS Config Generator Encrypted, and the old port actually closed Redis Sentinel Config Generator Failover that can actually be authorised
All 53 redis tools