3 ms·
How is this different from twemproxy[1]? EDIT: Looks like instead of using distinct ports to delineate separate clusters like twemproxy, it uses key prefix rou
by stock_toaster 12y ago
How is this different from twemproxy[1]?
EDIT: Looks like instead of using distinct ports to delineate separate clusters like twemproxy, it uses key prefix routing. It also supports "replicated pools", and a few other fancy/neat things. Interesting!
[1]: https://github.com/twitter/twemproxy https://github.com/twitter/twemproxy
- rbranson 12y agoOne 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.