KeySpace Notifications in Redis
The keyspace notifications in Redis are used to track the real-time changes to Redis keys and values.
Users can subscribe to Pub/Sub channels in Keyspace notifications to receive events that affect the Redis data set somehow.
The following are some examples of events that can be received:
- An RPUSH operation is performed on all keys.
- In database 0, all keys are about to expire.
- All commands that influence a specific key.
Type of events in Redis
For every operation affecting the Redis data space, keyspace notifications are executed by sending two different sorts of events. A DEL operation on the key named temp_key in database 0, for example, will result in the delivery of two messages, which are exactly similar to the following two PUBLISH commands:
PUBLISH __keyspace@0__:mykey del
PUBLISH __keyevent@0__:del mykey
The first channel monitors all events involving the key temp_key, whereas the second monitors only del operation events involving the key temp_key.
A Key-space notification is an event with the keyspace prefix in the channel, while a Key-event notification is an event with the keyevent prefix in the channel.
A del event was triggered for the key temp_key in the previous example, resulting in two messages:
- The Key-space channel receives a message with the name of the event.
- The Key-event channel receives as a message the name of the key.
It is acceptable to allow only one type of notification to deliver only the events that we care about.
Configuration in Redis
Since the notifications in Redis take up some memory and CPU power, they are kept disabled by default to conserve both the CPU power and the system memory.
With the help of the CONFIG SET, one can enable the event notifications in Redis. It can also be done using the notify-keyspace-events of Redis.conf.
Notifications are disabled when the argument is set to the empty string. To enable the functionality, a non-empty string made up of multiple characters is used, with each character having a unique meaning.
Some characters with their meanings are given below for reference
- K means Keyspace events,
- E means Keyevent events,
- G means Generic commands,
- $ means String commands,
- l means List commands,
- s means Set commands,
- h means Hash commands.
If neither K nor E are included in the string, no event will be delivered, regardless of the rest of the string's contents. So it is compulsory to include K or E.
For example, if we wish to enable the notifications only for the key-event events for hashes, then to do so, we have to use the command Eh. E to specify keyevent events and h to denote that we only want to enable the notifications for hash commands.
Every potential event can be enabled using the string KEA.
Events generated by different commands
Different commands produce kinds of events. The six most standard keys, as well as the events that are generated by Redis commands, are listed below.
-
DEL: For each removed key, a del event is generated.
-
RENAME: It generates two events. The events are the rename_from event for the source key and the rename_to event for the destination key.
-
MOVE: Similar to rename key, it generates two events, a move_from event for the source key and a move_to event for the destination key.
-
COPY: It creates a copy_to event.
-
MIGRATE: A DEL event is created if the source key is missing.
-
RESTORE: A restore event for the key is generated.
Note: All commands only generate events if the target key is changed. An SREM deleting a non-existing element from a Set, for example, will not modify the value of the key; hence no event will be triggered.
Timing of expired events
Redis can expire keys with a time to live in one of two ways:
- When a command attempts to access the key and discovers it has expired.
- Through a background system that searches for expired keys in the background gradually to gather keys that have never been used.
The expired events are created when one of the systems, as mentioned above, accesses a key and determines that it has expired. As a result, there are no assurances that the Redis server will be able to generate the expired event when the key time to live approaches zero.
There can be a substantial delay between the time the key time to live goes to zero and the time the expired event is created if no command targets the key regularly and there are several keys with a TTL linked.
Expired events are issued when the Redis server deletes a key rather than when the time to live potentially approaches zero.
Events in a cluster
As mentioned above, each node in a Redis cluster generates events concerning its subset of the keyspace. The alerts for events, unlike typical Pub/Sub communication in a cluster, are not sent to all nodes. To put it another way, keyspace events are unique to each node. This implies that clients must subscribe to each node in a cluster to get all keyspace events.
Frequently Asked Questions
-
What is Redis?
Millions of developers use Redis. It is an open-source in-memory data store used as a database, cache, streaming engine, and message broker.
-
What is Keyspace in Redis?
The internal dictionary that Redis maintains, in which all keys are kept, is called keyspace.
-
Why do we need keyspace notifications in Redis?
The keyspace notifications in Redis are used to track the real-time changes to Redis keys and values.
-
What does the RENAME key generate?
It generates two events. The events are the rename_from event for the source key and the rename_to event for the destination key.
-
What does the copy key generate?
The copy key in Redis generates a copy_to event.
Conclusions
In this article, we discussed Redis and Keyspace notifications in Redis. We also how to enable keyspace notifications in Redis. To learn about the different tools that use Redis go to Tools That Use Redis. Hope you would have gained a better understanding of these topics now!
Are you planning to ace the interviews of reputed product-based companies like Amazon, Google, Microsoft, and more?
Attempt our Online Mock Test Series on Coding Ninjas Studio now!
Happy Coding!