The problem/use-case that the feature addresses
Implementing client side caching in addition to using Redis as a distributed cache.
Example client will enable client tracking:
CLIENT TRACKING on
PSUBSCRIBE __redis__:*
When a key is deleted, or expired via TTL, the same messages are sent to the client:
1) "invalidate"
2) 1) "MY_KEY"
In the situation where (1) key is deleted, this can indicate that the associated value in invalid and should be removed from all other clients. In the situation where (2) the key had expired via TTL, this does not necessarily indicate that the value is invalid and does not need to be removed from other clients.
Description of the feature
A way to differentiate between keys expiring, and keys being deleted when client tracking is enabled.
Alternatives you've considered
Could be solved by custom pub/sub events
Additional information
N/A
All and any input is appreciated! Thanks!
Comment From: sundb
If you want to distinguish between them, you should use the event notification.
Comment From: spicalous
Thanks! I assume that's less performant than client tracking, as the docs say that enabling keyspace events notifs are disabled by default as it consumes some CPU resource
From the docs
By default keyspace event notifications are disabled because while not very sensible the feature uses some CPU power. Notifications are enabled using the notify-keyspace-events of redis.conf or via the CONFIG SET.
Comment From: sundb
Thanks! I assume that's less performant than client tracking, as the docs say that enabling keyspace events notifs are disabled by default as it consumes some CPU resource
From the docs
By default keyspace event notifications are disabled because while not very sensible the feature uses some CPU power. Notifications are enabled using the notify-keyspace-events of redis.conf or via the CONFIG SET.
yes, event notification is more expensive and you can listen for only the events you need instead of all of them.