memcached клиентский интерфейс поддерживает много различных алгоритмов распределения, которые используются в конфигурациях мультисервера, чтобы определить, какой узел должен использоваться, устанавливая или получая данные от приведенного memcached примера. Когда Вы получаете или устанавливаете значение, хеш создается из предоставленного ключа и затем используется, чтобы выбрать узел из списка сконфигурированных серверов. Поскольку хеширующий механизм использует предоставленный ключ в качестве основания для хеша, тот же самый сервер выбирается и во время набора, и получите операции.

Можно думать об этом процессе следующим образом. Учитывая массив серверов (a, b, и c), клиент использует алгоритм хеширования, который возвращает целое число, основанное на ключе, сохраненном или полученном. Получающееся значение тогда используется, чтобы выбрать сервер из списка серверов, сконфигурированных в клиенте. Самый стандартный клиент, хеширующий в пределах memcache клиентов, использует простое вычисление модуля на значении против числа сконфигурированных memcached серверов. Можно суммировать процесс в псевдокоде как:

@memcservers = ['a.memc','b.memc','c.memc'];$value = hash($key);$chosen = $value % length(@memcservers);

Замена вышеупомянутого со значениями:

@memcservers = ['a.memc','b.memc','c.memc'];$value = hash('myid');$chosen = 7009 % 3;

В вышеупомянутом примере выбирает клиентский алгоритм хеширования, сервер в индексируют 1 (7009 % 3 = 1), и хранилище или получает ключ и значение с тем сервером.

Можно видеть графическое изображение этого ниже в рисунке 15.5, "Выбор Хеша memcached".

То же самое хеширование и процесс выбора имеет место во время любой работы на указанном ключе в пределах memcached клиента.

Используя этот метод обеспечивает много преимуществ:

Если это, список серверов, сконфигурированных в пределах клиента, остается тем же самым, тот же самый сохраненный ключ, возвращает то же самое значение, и поэтому выбирает тот же самый сервер.

Однако, если Вы не используете тот же самый хеширующий механизм тогда, те же самые данные могут быть записаны на различных серверах различными интерфейсами, и тратящими впустую пространство на Ваш memcached и приводящими к разностям потенциалов в информации.

Проблема с клиентским выбором сервера состоит в том, что список серверов (включая их последовательный порядок) должен остаться непротиворечивым на каждом клиенте, использующем memcached серверы, и серверы должны быть доступными. Если Вы пытаетесь выполнить работу на ключе когда:

Если новый memcached экземпляр добавляется в список серверов, как new.memc находится в примере ниже, затем ПОЛУЧИТЬ работа, используя тот же самый ключ, myid, может привести к неудачному обращению в кэш. Это - то, потому что то же самое значение вычисляется от ключа, который выбирает то же самое, индексируют от массива серверов, но индексируют 2 теперь точки к новому серверу, не серверу c.memc где данные первоначально хранились. Это привело бы к неудачному обращению в кэш, даже при том, что ключ существует в пределах кэша на другом memcached экземпляре.

Это означает это серверы c.memc и new.memc оба содержат информацию для ключа myid, но информация, хранившая против ключа eachs сервер, может отличаться в каждом экземпляре. Более существенной проблемой является намного более высокое число неудачных обращений в кэш, получая данные, поскольку добавление нового сервера изменяет распределение ключей, и это поочередно требует восстановления кэшированных данных на memcached экземплярах, вызывая увеличение чтений базы данных.

Тот же самый эффект может произойти, если Вы активно управляете списком серверов, сконфигурированных в Ваших клиентах, добавляя и удаляя сконфигурированные memcached экземпляры, поскольку каждый экземпляр идентифицируется как являющийся доступным. Например, удаление memcached экземпляра, когда клиент замечает, что с экземпляром больше нельзя связаться, может заставить выбор сервера перестать работать как описано здесь.

Чтобы предотвратить этот вызывающие существенные проблемы и лишение законной силы Вашего кэша, можно выбрать алгоритм хеширования, используемый, чтобы выбрать сервер. Есть два общих типа алгоритма хеширования, непротиворечивого и modula.

С непротиворечивыми алгоритмами хеширования тот же самый ключ когда применено к список серверов всегда использует тот же самый сервер, чтобы сохранить или получить ключи, даже если список сконфигурированных серверов изменяется. Это означает, что можно добавить и удалить серверы из сконфигурировать списка и всегда использовать тот же самый сервер для данного ключа. Есть два типа непротиворечивых доступных алгоритмов хеширования, Ketama и Wheel. Оба типа поддерживаются libmemcached, и реализации доступны для PHP и Java.

У любого непротиворечивого алгоритма хеширования есть некоторые ограничения. Когда Вы добавляете серверы к существующему списку сконфигурированных серверов, ключи распределяются новым серверам как часть нормального распределения. Когда Вы удаляете серверы из списка, ключи перераспределяются к другому серверу в пределах списка, означая, что кэш должен быть повторно заполнен с информацией. Кроме того, непротиворечивый алгоритм хеширования не решает вопрос, где Вы хотите непротиворечивый выбор сервера через многократные клиенты, но где каждый клиент содержит различный список серверов. Непротиворечивость осуществляется только в пределах единственного клиента.

С modula алгоритмом хеширования клиент выбирает сервер первыми вычислениями хеша и затем выбором сервера от списка сконфигурированных серверов. Как список изменений серверов, таким образом, сервер, выбранный при использовании modula алгоритма хеширования также, изменяется. Результатом является поведение, описанное выше; изменения к списку серверов означают, что различные серверы выбираются, получая данные, приводя к неудачным обращениям в кэш и увеличению загрузки базы данных, поскольку кэш повторно отбирается с информацией.

Если Вы используете только единственный memcached экземпляр для каждого клиента, или Ваш список memcached серверов, сконфигурированных для клиента никогда, не изменяется, то выбор алгоритма хеширования не важен, поскольку это не имеет никакого значимого эффекта.

Если Вы регулярно изменяете свои серверы, или Вы используете единый набор серверов, которые совместно используются среди большого количества клиентов, то использование непротиворечивого алгоритма хеширования должно помочь гарантировать, что Ваши данные кэша не дублируются, и данные равномерно распределяются.