Redis Keyspace Notifications with flushdb

Question

The keyspace notifications have been essential for a recent web api I've been developing.

We have redis setup in azure. The api mostly works, we use notifications to figure out if data on memory cache needs to be updated.

Right now, we want to handle notifying the flush event to clear local memory cache if redis database is flushed. But we can not get the flushdb event by Keyspace notification. And the keyspace events is enable as "AKE". "AKE" string means all the events.

PS: we can get notification with 'set' event like '__keyevent@2__:set'

The subscription code is like below.

 subscriber.Subscribe(
            "*",
            (channel, value) =>
            {
                // Some codes here
            });

Answer 1

Just as the other answer mentioned, there's no such notification.

After all, Keyspace Notification is a notification for events on a single key. Each notification is associated with a key. For keyspace event, the key name is part of the channel name. For keyevent event, the key name is the message.

PUBLISH __keyspace@0__:key_name comamnd
PUBLISH __keyevent@0__:command key_name

Each command that sending a notification must have a key as argument. e.g. del key, set key val. However, the flushdb command has no key as argument. The command doesn't affect a single key. Instead, it removes all keys in the database. So there's no such notification for it. Otherwise, what do you expect from the channel? All keys that have been removed? It's not a good idea.

However, you can simulate an event for flushdb

1. set a special key, e.g. flushdb-event: set flushdb-event 0
2. subscribe on the corresponding channel: subscribe __keyspace@0__:flushdb-event
3. set the special key before you call flushdb: set flushdb-event 1

In this way, you can get the simulated flushdb notification.

Answer 2

According to Redis Documentation, there is no notification for Flushdb.

Answer 3

I think you have a couple of options.

1. You could call the INFO command periodically and check for a change in the number of flushdb or flushall calls. Here is the output from INFO that I am referring to...

   Commandstats

   cmdstat_flushall:calls=2,usec=112,usec_per_call=56.00 cmdstat_flushdb:calls=1,usec=110,usec_per_call=52.00

2. You could run the MONITOR command and parse the output. Note that this is not really a good option - it has heavy performance impact on the server side and would require a lot of processing on the client side.