If you want good failover, you should use the ketama method for server selection instead, the below naive server selection algorithm is bad in many ways.
However, if you think a bit more on failover, you'll also soon realize that it in itself will lead to unexpected behaviour. If a memcached server goes down and you have automatic failover, then your entire application can discover this at the same time and fail over at the same time, which is fine. But when that server comes back up again, it will automatically be restored into the cluster at different times by different parts of your application, which leads to your cache data being unsynchronized, which may or may not be fatal for your application. So if you want to make any changes to these clients, the best thing you could do is add an option to disable failover. :-) /Henrik On Mon, Jun 22, 2009 at 19:31, Pau <[email protected]> wrote: > > Hi to all, I'm a new in a list. > > This last days i spend some time thinking about how memcache - client > side - do some failover strategie in one pool of memcached servers. > Yes I have read the FAQ of memcached and this comment a lot of thinks > about memcached and that tool is not a distributed system, hence it's > responsability of client side build a "consistent" cache architecture, > but php and python - pure lib clients without linking to libmemcache - > have been written for memcache team, can you help me with next > question ? > > At first time I thought client api used some easy approximation to > build one "failover" hash strategy to avoid some connect errors, for > example : > > server = hash(key) % n_servers > while( connect(server, ...) AND i < max_retries ) > { i++; server++; } > > But I was wrong, php and python client using a different concept like > to this : > > server = hash(key); > while( connect(server % n_servers, ...) AND i < max_retries ) > { > i++; > server += hash(key + str(i)) ; > } > > This kind of approximation can has a dont expected behaviour, all > server values in all iteration can be projected in same integer range > and only try to connect a subgroup of server pool more lesser than all > group. > > Python and php hash strategies are different, one plus string value at > end of hash value and the other plus string at init of hash with some > rotate bit tricks, but in definitely all of them have the same > behavior. > > What do you think about is ? > > >
