4 ms·
> It is hugely more convenient and usable than cron. Once you have it, you immediately spot lots of opportunities to factor systems into scheduled jobs that you
by recuter 14y ago
> It is hugely more convenient and usable than cron. Once you have it, you immediately spot lots of opportunities to factor systems into scheduled jobs that you might have avoided doing if it meant you had to deal with cron.
That's actually pretty interesting. Can you give a few examples that fall out of having a more fine grained (millisecond) resolution?
- tptacek 14y agoOne example that jumps to mind was that I was able to rip out several hundred lines of fiddley retry and backoff code and replace it with fine-grain-timed repeating events. One advantage to doing this in Redis was that our events aren't just "run a program" (though we can do that); we can also push onto a queue that consumers BLPOP from, or send a pubsub message to a bunch of consumers, or increment counters. later Makes you think, it's nice that Redis is minimal, but a core feature that might work really nicely with Redis is timer support.
- thezilch 14y agoYou will get said timer support in Redis 2.8 with the ability to subscribe to keyspace events, which includes keys expiring (with millisecond resolution). https://github.com/antirez/redis/issues/594 https://github.com/antirez/redis/issues/594 psubscribe __keyevent@0__:expired cron_* psetex cron_run-me-in-1s 1000 0
- jeromeparadis 14y agoAwesome! I've been waiting for this for a while.
- kelnos 14y agoIt's not clear to me from the writeup if you'll get notification when the key actually expires, or when the key is expired because someone tried to access it. Currently keys don't actually really expire from the datastore until someone tries to access it after its TTL runs out. Changing redis so it will actually actively expire keys at the precise time the TTL runs down sounds expensive... but I would love that feature nonetheless.