Hi Rachel, For assertation 2, yes, it's a matter of chance which key is stored in which server, but depending on which server selection algorithm you use, you can determine the probability of a key being stored on the same server from both clients. (It's higher if you use Ketama) Still, you should never run memcached with differently configured clients, since that makes it non-synchronized which can be pretty fatal for you application.
For your questions, it depends again on the server selection algorithm. If you use the Ketama one, the order of the clients doesn't matter, but their names do. If you use the naive one, the names of the clients doesn't matter, but their order does. /Henrik On Fri, Mar 20, 2009 at 11:02, Rachel <[email protected]> wrote: > > I'd just like to check that my understanding of how a distributed > memcached system works. Are these 2 assertions correct? > > 1) It's the client which is configured to know about multiple > memcached servers; the servers themselves know nothing about being > part of a cluster. > > 2) If you have one client configured to use servers A and B, and a 2nd > client configured to use servers A,B and C, the results will be > indeterminate. The clients may use the same servers for the same key, > or they may not - it's just a matter of chance. > > Questions: > > 1) Does the ordering of the servers matter in the client? If client 1 > uses server A and server B, while client 2 uses server B and server A, > will they hash the same? > > 2) Does the server name matter? If client 1 uses > name.memached.localnetwork and client 2 uses 192.168.0.1, will they > hash the same? > > Thanks > Rachel
