Lua scripting for Redis
This article is based on A Speed Guide to Redis Lua Scripting from the IBM Compose blog. In this post, we’ll introduce Lua scripting for Redis, but unlike the original article, we’ve made it so all the commands work with IBM Cloud Databases for Redis.
Lua is a language which has been around since 1993. Its origins in engineering made for a compact language which could be embedded in other applications. It’s been embedded in applications as diverse as World of Warcraft and the Nginx web server. And Redis, which is why we are here. If you’ve already got your Databases for Redis database set up, along with the IBM Cloud CLI and tools, skip over this next section.
Connecting to Redis
We’re running the IBM Cloud CLI with the IBM Cloud Databases plugin. You can find out how to install them in Command Line Tools for Redis. The
cxn subcommand looks up the database name and the
-s flag says “Start an interactive shell.” We also pass the password with the
-p flag. The plugin works out what command and configuration are needed and runs the command. For Databases for Redis, that’s the
redli command. So, once you’ve installed the IBM Cloud CLI, IBM Cloud Databases plugin, and redli, you can get an interactive shell quickly. If you create a database called “MyRedis,” all you need to run is:
It’ll prompt you for a password. Then you’ll meet the interactive shell:
You can get to exploring Redis now—or in this case, Redis Lua scripts.
What does Redis let you do with Lua?
It lets you create your own scripted extensions to the Redis database. That means that with Redis, you can execute Lua scripts like this:
The string after the EVAL is the Lua script:
So at its simplest, you can run Lua scripts. But more importantly, you can run Lua scripts that act like an intelligent transaction. You can handle errors smartly, so instead of just rolling back, you can carry on processing. Of course, the intelligence of the transaction will be up to you.
But to start tapping into that power, you’ll probably want to pass the script some keys and arguments.
Keys and arguments?
The 0 at the end of the EVAL is the number of keys being passed to the Lua code; in that example, there were none. But if instead of 0 it was
2 foo bar fizz buzz, then the first two items in the list,
bar, would be passed as keys and
buzz would be arguments.
If you do pass keys, they are available to the Lua script in the KEYS table (a table is Lua’s associative array, which also is used as an 1-based array). If you have arguments, they appear in the ARGV table. For example:
.. is Lua’s string concatenation operator—this returns whatever the argument is concatenated with a space and then the key name given in the arguments.
No magic is applied to the KEYS, they are just strings so we still have to look up their value.
And how do you call Redis from inside Lua?
We can get at Redis’s functions through the
redis.call() command. If we use this script:
And then we EVAL it, assuming we’ve
SET the key
name:first to something, we’ll see this:
(Note: If you get
attempt to concatenate a boolean value as a response, then it’s likely you haven’t set the
name:first key to a value).
So now, in a script, we’ve taken a parameter, looked up a key’s value, and created a string and returned that as a result.
This EVAL command is going to get pretty messy isn’t it?
Yes. That’s why there are other ways to get Lua scripts up to the server. The one we like is by using the command line arguments of the
redis-cli) command. Just write your “more complex” Lua script:
We’ll save that as
longhello.lua and then run this at the command line:
This looks a little like the command we used at the beginning to connect to the interactive shell. Apart from also passing the password with the
-p flag, this command shows another way to use the plugin. Behind the scenes, the plugin works out what command and configuration are needed to run the command. Everything it finds after the
-- then becomes arguments and flags for that command. Here, we’re add a
This the new bit,
--eval, lets you name a file to be sent up to the server and EVAL’d. So we follow that with
longhello.lua. Now our script needs keys and arguments. The keys come first and redli (and redis-cli) counts them for us; each command line parameter is a key, right up to the comma. What comes after the comma are arguments.
We can now write Lua code for Redis locally and quickly test it on the server, even a remote one.
I’m pretty good for greetings functions, got anything meatier?
Why yes, here’s a little problem for you that Lua solves nicely. Consider a situation where various divisions of a company increment different counters in the big scheme of things. So say “region:one” bumps the counter keys “count:emea,” “count:usa,” and “count:atlantic,” while “region:two” just bumps “count:usa.” These counter lists may be added to in the future, but you really want to make sure it happens all in one fell swoop. Remember what we said about this being an “intelligent transaction”? Well, here we can do all that in one script.
Let’s set up our regions as lists:
Now we’ll create a Lua script locally:
We start with a count variable—we will count all the increments we do and return that value:
Here we ask Redis to give us all the values in the list that should be referred to in the first key:
This is the opener of a Lua for loop. The ipairs function iterates through the Lua table we just got in order and we take the key from each:
And for each key, we ask Redis to increment it. Oh, and then we bump up our counter. And that’s nearly it. All that’s left is . . .
. . . to end the for loop and return the count. Save that to a file and then run it with an argument:
And, if we go look, we find:
If we use the script on region 2:
So now we’ve got ourselves a useful little function. What if there was an error? Ah, well as it stands, this script would error out too. That’s because we’re using
redis.call(), which explicitly does that. If we used
redis.pcall(), if there was an error, the error details would be returned instead and we could decide what to do. But this is a speed guide and . . .
Wait a minute, I have to upload the script every time?
No, Redis has a script cache and a command SCRIPT LOAD to just load scripts into the cache. We’ll use it from the command line here, but you can incorporate it into your applications like any other Redis command:
"$(cat broadcast.lua)" just turns our script into a quoted argument. The important bit is the number that comes back (it’s in hex). It’s the SHA1 signature of the script. We can use this to invoke the script using the
EVALSHA command like this:
There are commands to check for scripts (
SCRIPT EXISTS) and to flush them out (
SCRIPT FLUSH) so you can manage your script loading too.
So what’s the catch?
After a particular time limit (five seconds by default), Lua scripts will start getting errors in response to queries and an error will be written to the log—the only commands available will either kill the script (
KILL SCRIPT) or shut down the server (
SHUTDOWN NOSAVE) in that situation. The five-second time limit is insanely generous as you should be writing your Lua scripts to run very quickly, in milliseconds. Why? Because while your script is running, everything else is on hold.
Hey, Lua has a lot of libraries, can I use them?
The EVAL commands documentation is where you start as it goes into detail on how Redis types are converted to Lua types. The Lua Manual covers the entire language; and remember there are versions to download that you can run outside Redis for practice. There’s also an alternative introduction from 2013 which touches on using the libraries and common gotchas too.