гипотетически – если у меня есть несколько серверов memcached, например:
//PHP $MEMCACHE_SERVERS = array( "10.1.1.1", //web1 "10.1.1.2", //web2 "10.1.1.3", //web3 ); $memcache = new Memcache(); foreach($MEMCACHE_SERVERS as $server){ $memcache->addServer ( $server ); } И затем я установил данные следующим образом:
$huge_data_for_frong_page = 'some data blah blah blah'; $memcache->set("huge_data_for_frong_page", $huge_data_for_frong_page);
И затем я получаю данные следующим образом:
$huge_data_for_frong_page = $memcache->get("huge_data_for_frong_page");
Когда я захочу получить эти данные с серверов memcached – как php memcached-клиент узнает, какой сервер запрашивает эти данные? Или клиент memcached будет запрашивать все серверы memcached?
Ну, вы можете писать книги об этом, но базовый принцип заключается в том, что существуют разные подходы.
Наиболее распространенный и понятный подход к кешированию – это осколки. Это означает, что данные хранятся только на одном сервере, и какой-то метод используется для определения того, какой сервер это. Таким образом, он может быть получен с этого самого сервера, и задействован только один сервер.
Это, очевидно, хорошо работает в средах с ключом / значением, например memcached.
Общей практикой является криптографический хэш ключа. Вычислите этот хэш MOD номер сервера, и результатом будет сервер, который вы будете хранить и извлекать данные.
Эта процедура обеспечивает более или менее равномерную балансировку.
Как это точно сделано в memcached i dunno, но какой-то хеш наверняка.
Но будьте осторожны, что этот teqnique не очень доступен. Поэтому, если один сервер не прошел, записи исчезли. Поэтому вы, очевидно, можете использовать это только для кеширования.
Другие тегики, где, например, необходима высокая доступность ресурсов, которые занимают много времени, чтобы рассчитать и автоматически нагреваться в фоновом режиме, включают репликацию.
Наиболее распространенной формой в средах кэширования является репликация master-master с разрешением конфликтов с последней меткой. Это означает, что каждый сервер получает данные с everyserver, которые еще не находятся на локальном сервере (это делается с использованием журналов репликации и смещений байтов). Если есть конфликт, используется последняя версия (незначительное смещение времени между серверами игнорируется).
Но в других средах, где для примера написано очень мало, но много читается, часто возникает каскад, где задействованы только один или несколько главных серверов, а остальная часть – просто чистая репликация.
Но эти настройки очень редки, потому что очертание, как описано, дает наилучшую производительность, а в средах кеширования потери данных в основном переносимы. поэтому его также по умолчанию для memcached.
несколько дней назад я искал решение для оптимизации масштабирования наших серверов memcached и нашел этот ответ. Из опыта, который мы сделали, дескриптивное решение с генерацией хэша и количеством номеров MOD для поиска целевого сервера не является лучшим.
Если вы увеличите или уменьшите количество своих серверов, это может привести к тому же сценарию при очистке кеша. Большинство хэшей получают другой сервер, поэтому не будет результата из кэша для первого запроса.
Лучшим решением для использования в таких сценариях является последовательное хеширование. При постоянном хешировании каждый сервер получает фиксированный хехранг. Поэтому, если вы теперь увеличиваете или уменьшаете количество серверов, только хеши в этом конкретном хэшранге будут переключены на другой сервер. Все остальные хэши остаются там серверами, и только небольшая часть будет восстановлена.
Для PHP есть библиотека под названием «flexihash», которая делает последовательное хеширование для вас.
В нашем блоге вы можете найти пример, как использовать его со своим собственным клиентом-кешем. Статья находится на немецком языке, но исходный код должен быть необъяснен.