Memcached против HW Load Balancer с липкими сессиями - PullRequest
3 голосов
/ 12 октября 2010

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

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

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

Ответы [ 3 ]

3 голосов
/ 13 октября 2010

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

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

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

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

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

3 голосов
/ 14 октября 2010

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

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

2 голосов
/ 13 октября 2010

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

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

...