Memcached *ByKey

Значит, нагуглилось не сразу, но все же. Кто знаком с инглишом, тут http://code.google.com/p/memcached/wiki ... Master-Key

В двух словах. Кей сервера - это такая же случайная строчка.
Те, кто работает с мемкешом, знает, что если у нас 10 серверов, то при операциях чтения/записи библиотека на основе ключа выбирает сервер и работает с ним. Таким образом осуществляется горизонтальное масштабирование (подчеркну - это делает библиотека, а не сами мемкеш сервера).

Так же многие знают, что есть операция можественного чтения (mget), что бы получить пачку ключей сразу. mget поддерживается в протоколе общения с серверами, т.е. библиотека не делает сотню get, а просто передает один mget на сервер.

Возьму пример из статьи. Есть юзер, и у него куча свойств (какие-нить времена доступа, биографичные данные и т.д. и т.п.). Все данные храняться отдельными ключами, типа user_id:age, user_id:lastvisit и т.д. Для того, что бы взять все данные по юзерю используем mget и получаем данные пачкой. Чудно.

Но что происходит, если у нас 10 (50, 100, 1000) серверов мемкеш? Каждый ключ может оказаться на своем отдельном сервере. И библиотеке вместо одного запроса mget на один сервер придется делать по запросу на каждый сервер. На лицо огромный оверхед, особо если данные крохотные по размеру. И вот что бы это избежать, придумали master_key.

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

Что это нам дает? Использовав как мастер кей ключ "user_id", мы будем уверены, что user_id:age, user_id:lastvisit и т.д. будет храниться на одном физическом сервере, а значит mget по этим ключам пойдет на один физический серер, а не будет размазано по всему кластеру.

Итак, мастер кей (или server_key по пхп-шному) - это произвольный ключ, на основе которого, используя стандартный алгоритм выбора сервера, этот сервер будет выбран. В этом случае обычный key (второй параметр) не используется для выбора сервера, а отправляется на предварительно выбранный.

 

Ключи выдуманы. Это метод, который позволяет показать, какой сервер будет выбран на основе того или иного ключа.
mem1.domain.com отсуствует потому, что ключи не показывают на него. Выбор сервера в принципе банален. Если есть массив серверов serverList и его длина serverList.length, то нужный сервер - это
serverList[ hash(key) % serverList.length ]
где hash - алгоритм хеширования... в ketama там вроде сначала получается md5 от ключа, а после еще несколько логических операций над md5 хешом.