4 ms·
> "way more reliable than Redis." I respect your opinion on different messaging solutions (Resque VS Beanstalkd) however since we spend a lot of efforts to mak
by antirez 14y ago
> "way more reliable than Redis."
I respect your opinion on different messaging solutions (Resque VS Beanstalkd) however since we spend a lot of efforts to make sure Redis is very reliable I wonder what's the reliability problem you experienced with Redis. Thanks!
- pimeys 14y agoI don't know was it our devops lack of knowledge on Redis, but we had couple of times when we just lost thousands of work items. Redis is very good for different data structures, like hashes or lists, but for queuing I really prefer Beanstalkd over anything.
- andrewvc 14y agoThat was a pretty big accusation to throw around, that red is just lost data. It was more likely resque or perhaps even your own fault. As far as perf goes, redis queuing is just a linked list. It is ridiculously fast, I would really like to see numbers backing up your claims. If you are going to make accusations like this you should at the very least understand why stuff broke.
- pimeys 14y agoWell, of course we'll need a retrying system with delay, so that's a sorted set then together with the work item list. I prefer simple solutions and I know it was our fault we got a data loss with Redis. Still Beanstalkd queues have been causing less pain than Resque and Redis together. Integrated delays, tubes and deadlines are really nice. Altogether the reliability comes from the deadlines. If my worker gets stuck (well, it's Ruby), we don't lose the work item. Doing pop on Redis will delete the item from the queue, but in Beanstalkd you reserve the item and delete it when you're done.
- deleted 14y ago[deleted]
- nirvdrum 14y agoA different issue, but one that's burned me several times is when things go wrong with resque (or sidekiq), life goes to hell pretty quickly because redis needs to fit everything in memory. E.g., if a third party resource goes down and jobs hitting it all of a sudden start exceptioning and get thrown into a retry queue, all those stacktraces sitting around in memory accumulate very quickly. redis fills up, the OS kills it, it starts back up, loading an older DB, and then restarts processing all those jobs that just failed, without an exponential backoff. And this process will basically repeat ad nauseum. I'm not sure a whole lot can be done, other than resurrecting the old debate over something like diskstore. And while EC2 is memory-constrained, dealing with this situation isn't a matter of just adding more memory, because that will be filled up as well. redis would either need to be able to spill over onto disk or the processing model would need to be changed. We ended up doing the latter, eschewing stacktraces for retried jobs, adding monitoring to disable queues that have a very high failure rate, etc.
- rahoulb 14y agoI'll second this. It's the Resque backtraces that have caused us a few problems. And on a VPS RAM is your most expensive resource, possibly making Resque/Redis not such a good fit.
- deleted 14y ago[deleted]
- mercuryrising 14y agoIf I ever come to Italy, I'm buying you a beer.