$value = hash($key);
$chosen = $value % length(@memcservers);
Replacing the above with values:
@memcservers = ['a.memc','b.memc','c.memc'];
$value = hash('myid');
$chosen = 7009 % 3;
In the above example, the client hashing algorithm chooses the server at index 1 ( 7009 % 3 = 1),
and store or retrieve the key and value with that server.
Using this method provides a number of advantages:
? The hashing and selection of the server to contact is handled entirely within the client. This
eliminates the need to perform network communication to determine the right machine to contact.
? Because the determination of the memcached server occurs entirely within the client, the server can
be selected automatically regardless of the operation being executed (set, get, increment, etc.).
? Because the determination is handled within the client, the hashing algorithm returns the same value
for a given key; values are not affected or reset by differences in the server environment.
? Selection is very fast. The hashing algorithm on the key value is quick and the resulting selection of
the server is from a simple array of available machines.
? Using client-side hashing simplifies the distribution of data over each memcached server. Natural
distribution of the values returned by the hashing algorithm means that keys are automatically spread
over the available servers.
Providing that the list of servers configured within the client remains the same, the same stored key
returns the same value, and therefore selects the same server.
However, if you do not use the same hashing mechanism then the same data may be recorded
on different servers by different interfaces, both wasting space on your memcached and leading to
potential differences in the information.
The problem with client-side selection of the server is that the list of the servers (including their
sequential order) must remain consistent on each client using the memcached servers, and the servers
must be available. If you try to perform an operation on a key when:
? A new memcached instance has been added to the list of available instances
? A memcached instance has been removed from the list of available instances
? The order of the memcached instances has changed
When the hashing algorithm is used on the given key, but with a different list of servers, the hash
calculation may choose a different server from the list.
If a new memcached instance is added into the list of servers, as new.memc is in the example below,
then a GET operation using the same key, myid, can result in a cache-miss. This is because the same
value is computed from the key, which selects the same index from the array of servers, but index 2
now points to the new server, not the server c.memc where the data was originally stored. This would
result in a cache miss, even though the key exists within the cache on another memcached instance.
This means that servers c.memc and new.memc both contain the information for key myid, but the
problem is a much higher number of cache-misses when retrieving data, as the addition of a new
server changes the distribution of keys, and this in turn requires rebuilding the cached data on the
memcached instances, causing an increase in database reads.
The same effect can occur if you actively manage the list of servers configured in your clients, addingand removing the configured memcached instances as each in