Jobs are persisted to a tokyo tyrant backing store. Beanstalkd
(No failover or discovery, but yes restarting and reloading.)
Weaknesses? Mainly that it will make an Erlang’er cry for its lack of concurrency correctness. Its goal is to work pretty well and to recover gracefully, but its design limits .
From a production server:
%CPU %MEM VSZ RSS Command 0.2 0.5 231044 67424 /usr/local/bin/ttserver -host 0.0.0.0 -port 11212 -log /var/log/god/ttyrant_11212.log /data/distdb/flat_delay_queue.tct 0.1 6.4 798440 783580 /usr/local/bin/beanstalkd -l 0.0.0.0 -p 11210 -z 65535
With about 1M jobs in the db+queue, beanstalkd is taking up about 800MB memory and tyrant less than 100MB. (This is with the full job object stored in the queue: memory pig but faster)