I am using Redis for cache some key value pairs.And I put TTL for that keys So it should be deleted after that timeout.But instead of deletion I want to reset the value when the key expires.Is that possible? If so can anyone send me how to do this? Or if not possible is there any other solution for this usecase.
This isn't possible using regular Redis TTL.
Alternatively, you'll need to implement that using some application-layer scheduled job to both implement a custom TTL and the custom action to reset the value.
Do you know Quartz?
Related
I am new to using Redis and have been tinkering around with it to get a better idea of how it all works. I have a queue called available_workers:queue of values (workers) where the queue itself represents the overall state of available_workers. As I pop a value (worker) from the queue and use it, two things can happen:
The state of the worker does not change and is pushed back into the available_workers:queue.
The state of the worker does change (it becomes exhausted for a period of time) and a new key is created {id}:worker with a command such as SET 132303:worker worker_value EX 100
Is it possible to on expiration of the key 132303:worker to trigger a Redis command to push the value back to the available_workers:queue? I have read the official documentation but don't see what I am looking for... Is this even possible to do using something like Redis? Or will I need to create some service in code to manage this? Thanks in advance to all of those who reply!
You can make your own notifications just by calling PUBLISH alongside the calls that modify the data - for atomicity consider using transactions or a Lua script
PUBLISH __keyspace#0__:mykey del
PUBLISH __keyevent#0__:del mykey
Without using keyspace notifications, pub/sub and streams, is there a way to detect/listen to a key's value being changed (or a key being added to a hashmap) in Redis?
Thanks
I'm using Redis as distributed cache. I have different applications which listen only particular keys. For example:
App1 listen App1.*
App2 listen App2.* and so on.
And my applications using following pattern to receive notifications:
App1: "key*:APP1."
App2: "key*:APP2."
I need to send notifications only about set, del, expired, evicted events that is why I have tried to use notify-keyspace-events "AK". If works fine for me but in this case of "AK" configuration redis starts to send extra notifications like "expire" which I don't need.
So according to documentation http://redis.io/topics/notifications I have tried to implement custom property:
notify-keyspace-events "Ksxe" to send only set, expired and evicted notifications. But in fact in this case I receive only expired notifications..
Questions:
1. Why I doesn't receive set and evicted events?? Why I receive only expired events?
2. Is there any way to make redis send only del notifications??
I also have tried "Ks" but redis doesn't send notifications about set events
A Alias for g$lshzxe, so that the "AKE" string means all the events.
"Kg$lshzxe" doesn't works correctly too..
I think you are misunderstanding the "s" flag. It has nothing to do with the set command. It tells Redis to only send commands that alter keys of the type "redis set" such as sadd or a key of the Redis set type expiring.
Thus, in your example "Ksxe" you instruct Redis to send you a notification anytime a key containing a Redis set is evicted or "expired". The "Ks" options instruct Redis to only send you notifications on keys of the type "set" being altered, not when a string is created using set command. To translate that to english, you told Redis "tell me when a key of type 'set' is expired or evicted".
If you want to know when a key of the type string is created or altered using the set command, has an expiration added to it, setting an expiration immediately deletes the key, or is evicted, you need to instead use "K$xeg". The "g" is important because it catches use of the expire command itself, and the '$' indicates the string type.
Also note that the "g" flag will result in "expire" events, but an expiration event will be labelled as "expired", enabling you to tell the difference. If you don't care about the creation of a TTL on a key, you can leave off the "g".
I have a program that utilizes a redis key with an expire time set. I want to detect when there is a new entry to the data set. I can tell when there is a removal by listening for the "expired" event, but the "set" and "expire" events are fired every time the key is set, even if it's already in the database.
Is there a keyspace event for a NEW key appearing?
There's no keyspace configuration that detects that a key was overwritten vs. newly added.
If you are primarily using the SET command, you may be able to take advantage of the NX option and publish a custom event based on the result. Obviously this isn't an ideal approach, but it's something.
https://redis.io/commands/set
Example of a custom event:
PUBLISH __keyevent#0__:new_data_entry new_key
Details on that here: https://redis.io/topics/notifications#type-of-events
Hope that helps.
I have set an expiration value to a key in redis, and want to get the opportunity to run a piece of code before the key will be deleted by redis. Is it possible, and if so how...?
Thanks
My solution was to create a new key, with the same name as the one I wanted to hook, only I added a prefix for it indicating it's a key for timeouts usage ("TO") - something like:
set key1 data1
set TO_key1 ""
expire TO_key1 20
In the example above, as soon as "TO_key1" will expire, it will notify my program and I'll get the opportunity to run my code before I will manually delete "key1".
I found this link very useful for creating the listener for redis: Redis Key expire notification with Jedis
This isn't possible with standard OS Redis... yet. There is a way, however, to do something similar without too much hassle. If you stop using Redis' expiry (at least for those keys that you're interesting in "hooking") and manage expiry "manually" in your code, you can do anything you want before/during/after the expiry event.
Since Redis offers key-level expiry out of the box, people are usually content with it. In some cases, i.e.g. expiring members in a Set, the only way to go is the manual approach but that approach is still valid for regular keys when you need finer control.