3 ms·
One of the primary reasons we switched to it at Instagram (we were using twemproxy) is that it has much more robust failure handling than twemproxy did, at leas
by rbranson 12y ago
One of the primary reasons we switched to it at Instagram (we were using twemproxy) is that it has much more robust failure handling than twemproxy did, at least at the time. That may have changed. Our experience was that if we lost a single memcache server, it caused multi-gets that included the lost server to fail completely or hang / timeout, instead of just not including results from the down host.
- stock_toaster 12y agoAt ($dayjob) we currently use twemproxy (30 nodes with ~4k get/s each), so this is very interesting to me. Thanks for the info/feedback.
- rbranson 12y agoTo elaborate: twemproxy supports auto_eject_hosts, but the host is removed from the ring until a timeout and it's portion of the keyspace is re-allocated to other machines during this time. There are numerous problems with this, but the biggest problem is that it causes inconsistent views of the ring if one or more client hosts is unable to reach some of the machines in the ring for transient periods of time, which is a pretty normal kind of thing if you've got clients and ring nodes distributed over multiple loosely coupled failure domains. mcrouter is much more capable in terms of handling node failure.