Memcached против HW Load Balancer с липкими сессиями

Все, я провел некоторое исследование того, когда (а когда нет) использовать Memcached. Я знаком с распределенным кешированием с точки зрения его основных целей. Для меня использование Memcacached / similar имеет смысл, если у вас есть несколько серверов ... поскольку это даст вам центральный виртуальный репозиторий для хранения ваших кэшированных данных.

Тем не менее, если у вас есть аппаратный балансировщик нагрузки (скажем, BigIP от F5), который может выполнять липкие сеансы - так ли выгодно иметь распределенный кеш? AFAIK, похоже, единственное, что вы будете делать в этом случае, - это убедиться, что вы не используете оперативную память вашего веб-сервера (ов) для кеширования. Есть ли какие-либо другие преимущества использования memcached в среде, где у вас уже есть аппаратные балансировщики нагрузки, которые используют липкие сеансы?

Насколько мне известно, включение липких сессий не требует больших затрат с точки зрения производительности. Очевидно, я мог ошибаться.


load-balancing load memcached
person Sanjay Uttam    schedule 12.10.2010    source источник

Ответы (3)


arrow_upward
3
arrow_downward

У нас есть как аппаратные балансировщики нагрузки, так и memcached. Они служат разным целям, и memcached не имеет ничего общего с липкими сессиями.

Это очень высокий уровень, но вы можете думать об этом так: балансировка нагрузки позволяет распределять запросы на ЦП и другие ресурсы по группе серверов. Однако memcached делает так, что вам вообще не нужны эти ресурсы.

Например, предположим, что у вас есть страница поиска и вы решили кэшировать результаты поиска. Допустим, у вас 20 серверов. Когда поступает поисковый запрос, он направляется на сервер, который мы можем назвать Сервером A. Этот сервер будет выполнять поиск, а затем кэшировать результаты в memcached.

Теперь, если тот же поисковый запрос поступает от другого сеанса или другого пользователя, он, вероятно, будет перенаправлен на другой сервер, Сервер B. Но сервер B сможет получить кешированные результаты из memcached, которые сервер A поместил туда, поэтому он никогда не придется искать.

Предостережение: это не применимо, если вы используете memcached для кеширования только вещей, которые зависят от сеанса и меняются от сеанса к сеансу, например уникального токена входа. Для этих вещей вы также можете кэшировать на сервере только с конкретным сеансом, если у вас есть липкие сеансы. Однако большинство вещей, которые стоит кэшировать, доступны более широко.

person Rohan Singh    schedule 12.10.2010

arrow_upward
3
arrow_downward

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

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

person Yiftach    schedule 13.10.2010
comment
Я просто не уверен, что memcached - лучшее решение для хранения сессий. Меня пугает мысль о том факте, что memcached может решить удалить старые существующие файлы cookie, если у него закончится память. Взгляните на Redis, Riak или аналогичные решения для хранения, которые не сокращают ваши сеансы и поддерживают высокую доступность / отказоустойчивость. - person Ztyx; 09.12.2011

arrow_upward
2
arrow_downward

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

Это не полный ответ, но это важный фактор, который следует учитывать.

person Mark    schedule 12.10.2010