Использование реплицированного кэша против липкого сеанса LB

Как всегда в распределенных системах, ответ зависит от разных вещей:

1. Балансировщик нагрузки с липкими сеансами - это, конечно, более простой способ для разработчика, поскольку он не имеет никакого значения, если приложение работает на 1, 2 или 100 серверах. Если это все, о чем вы заботитесь, придерживайтесь его, и вы можете прекратить читать прямо здесь.

2. Я не уверен, как реализованы балансиры балансировки сеанса, и каков их общий предел в отношении запросов в секунду, но у них есть хотя бы один большой недостаток в распределенном кеше. - Что делать, если машина, обрабатывающая сеансы, отключена? - Если вы распределяете свой кеш, любая машина может обслуживать запрос, и не имеет значения, если один из них не работает. Сериализация/десериализация не является большой проблемой, скорее, сеть может быть узким местом, если вы не запускаете ее, по крайней мере, в 1 Гбит сетевой среде, но это должно быть хорошо.

   • Для распределенного кеша можно использовать либо Hazelcast, Infinispan, либо аналогичные решения, что упростит доступ из вашего собственного приложения. (Обновление: эти реализации используют DHT для распространения кеша)
   • Полностью реплицированный кеш, вы можете использовать EhCached, который вы упомянули, или Infinispan. Здесь преимущество над распределенным кешем - это гораздо более быстрый доступ, так как у вас есть все данные, реплицированные на каждом компьютере, и им нужно только получить доступ к нему локально. Недостатком является более медленная запись (поэтому скорее используйте его для чтения очень часто, пишите очень редко сценарии) и тот факт, что ваш кеш ограничен суммой, которую может хранить один компьютер. Если вы используете приложения на серверах с 64 ГБ ОЗУ, это нормально. Если вы хотите распространять их по небольшим экземплярам amazon, это, вероятно, плохая идея. Я думаю, прежде чем вы столкнетесь с проблемами с обновлением слишком большого количества узлов, у вас будет AVG_CACHE_NEEDED_PER_CLIENT * NUMBER_OF_CLIENTS < MEMORY_FOR_CACHE_AVAILABLE (on one server) памяти, и ее, по крайней мере, очень легко вычислить: AVG_CACHE_NEEDED_PER_CLIENT * NUMBER_OF_CLIENTS < MEMORY_FOR_CACHE_AVAILABLE (on one server). Если вам нужно больше кеша, чем у вас на любом узле вашего кластера EhCached, полная репликация будет невозможна.
   • Или вы можете использовать кластер Redis или аналогичный независимо от вашего приложения и серверов, на которых работает ваше приложение. Это позволит вам масштабировать кеш с другой скоростью, чем остальная часть вашего приложения, однако доступ к данным не будет таким тривиальным.

Разумеется, фактическое решение зависит от вашего конкретного случая использования и требований, предъявляемых к вашей заявке.

Лично я был очень рад, когда узнал сегодня, что у Azure WebPages есть балансировщик нагрузки с поддержкой липкой сессии, и мне не нужно перенастраивать мое приложение, чтобы использовать Redis в качестве хранилища объектов сеансов и просто хранить все как есть.

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