Redis Best Practices

Distributed Events

The Pub/Sub messaging of Redis can be extended to create interesting distributed events. Let’s say we have a structure that is stored in a hash but we want to update clients of it only when a particular field exceeds a numerical value as defined by the subscriber. We’ll listen to a pattern of channels, and only then, fetch the hash at status. In this example, we’re only interested in update_status when it is between 5 and 9.

> PSUBSCRIBE update_status:[5-9]
1) "psubscribe"
2) "update_status:[5-9]"
3) (integer) 1
[waits]

To change the value of status/error_level, we’ll have a subroutine that runs two commands sequentially or in a MULTI/EXEC block. The first command sets the level and the second command publishes the notice, with the value encoded in the channel itself.

> HSET status error_level 5
(integer) 1
> PUBLISH update_status:5 0
(integer) 1

When a message is received our client application switches to an alternate client and issues the HGETALL command:

> HGETALL status
1) "error_level"
2) "5"
3) "last_error"
4) "Crawler returned 404"
5) "timestamp"
6) "1511467605734"

We can then use this to, say, update a local variable of a long-running process. This can allow multiple instances of the same process to “share” data in live way.

What’s nice about this pattern vs just using Pub/Sub is that when the process restarts, it can simply grab the entire status hash and start listening. The changes will then be synchronized across any number of processes. Should the instance become disconnected from the Redis server, then, as part of the reconnection, the server can grab the status hash and re-start listening.