Redis — Getting Notified When a Key is Expired or Changed

Credits to Brett Jordan (https://unsplash.com/photos/LPZy4da9aRo)

Have you ever heard of Redis Keyspace Notifications? Probably most of you already familiar with redis and even use it on daily basis, but do you know we can get “notified” if there is a key change / expiration happen?

What is this Keyspace Notifications?

Long story short, it’s a pubsub mechanism that allows you to listen for data change in redis. Simple usecases that might be beneficial using this feature for example likes, you want to get notified when some keys are expired, you want to monitor changes for a special key, and any other extension use cases you can think of.

If you want to look closely more details about this, you can visit this link

Redis Keyspace Notifications - Redis

Enough Chit Chat, Here is some example

Here are the steps to “use this feature”:

1. Enable the redis notification in redis.conf / using CONFIG SET command
2. Create a subscribe redis connection using determined key pattern

Regarding point number 1, it’s disabled by default, by the documentation it’s due to some CPU power is being used while this feature is enabled.

here is the example on my PC

Set the feature to be enable by using command

CONFIG SET notify-keyspace-events KEA

What does the KEA stands for? It’s basically set the feature to notify a lot of event, like LIST, SET, HASH, SORTED SET, EXPIRED KEY, EVICTED KEY, and so on, details can be read on the documentation page. You can configure it as needed, if you need only listen to LIST, HASH, and EXPIRED key modification then you can define it like KElhe for example.

Snippet based on the documentation

Then, we can subscribe for a pattern by using PSUBSCRIBE redis command

psubscribe stands for subscribe with your desired pattern (https://redis.io/commands/psubscribe)

We can test that our subscribed client get notified once a key is changed / set / expired. Create a separate terminal, then let say we’re sending this commands

SET mykey 20

EXPIRE mykey 10

I divide the left side to 3 sections so you can see it easier. After the first SET command, we got 2 notifications point 1–4 twice. I’ll try to explain it one by one. Look out this 4 lines (first message):

1.) pmessage
2.) __key*__:*
3.) __keyspace@0__:mykey
4.) set

When you set a key, redis will publish a pub sub message (point number 1), with a kind of “channel” point number 3 (with mykey is the key that is being changed, i guess 0 is the redis default DB?), in which we got since we listened to __key*__:* (subscribe pattern), and point number 4 is the command happened to that key, which is set.

In a way, mykey has been set for the first message.

Then look out the other 4 lines (second message):
1.) pmessage
2.) __key*__:*
3.) __keyevent@0__:set
4.) mykey

It’s similar to the previous one but we’re looking at different angle, when we did the SET command, redis also publish a pub sub message “key event” of set (point 3) for key mykey (point 4).

In a way, set has been happening on mykey for the second message.

For a SET command we’re getting two pub sub messages (above) because we listened (subscribe) to __key*__:* pattern. If we change our subscribe pattern command to for example __keyevent*:*, then we’ll get only the second message.

Last, look out for the last 2 messages (two 1–4 points). When the key does expire, we got notified also with the same pattern. The first message (keyspace) notify that mykey is expired. While the second message is stating that an expired event is happening on mykey.

Therefore, if you need some notification when your “monitored” key is changed / expired so you can put some handling in your application, it’ll be nice to try considering this key space notification feature in Redis.

Things to be Concerned (Must READ)

While this “feature” seems convenient to those of you who might need a use case like this. Please note several things from the documentation:

1. More cpu usage on redis is being used while the notification feature is on (I don’t know how much, maybe based on many event that is happening, how many keys exist, etc), that’s why the default config is off
2. PSUBSCRIBE command support by programming language can be vary depending on the library, I’ve tried using Golang redigo a few years back and it’s supported. You might want to check your programming / library support for a client subscribe / pattern to redis
3. Key expiration IS NOT REAL TIME, while it seems like a real time if you try on local (small key), it’s already stated in the doc that the key might not be notified real time upon expiration event due to redis expiration logic (read the Timing of expired events section of the doc)
4. If you use redis cluster, the notification event is independently happening on each node, if you want to get notified on all keys across nodes, you have to listen all of the nodes (see the Events in a cluster section in the docs)