Memcached vs. HW Load Balancer с липкими сеансами

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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