[recuter]

> 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]

One 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]

You 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

  psubscribe __keyevent@0__:expired cron_*

  psetex cron_run-me-in-1s 1000 0

[kelnos]

It'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.

[thezilch]

Redis's expirey strategy has changed as of Redis 2.6, which does have Redis actively expiring keys.

[kelnos]

Ah! I did not know this! This may make a few things simpler for me...

[jeromeparadis]

Awesome! I've been waiting for this for a while.