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

Question

Мне нужно сохранить некоторые данные в кеше на сервере. Серверы находятся в кластере, и вызов может перейти к любому из них. В таком случае лучше использовать реплицированный/распределенный кеш, например EhCache, или использовать сессионную липкость LB.

Если размер данных (в кеше) большой, не повлияет ли это на производительность сериализации и де-сериализации на всех серверах?

Также в случае распределенного кеша, какое оптимальное количество серверов, до которых такой кеш действует. Так как данные реплицируются на все узлы и говорят, что число узлов равно 20, то он, как и master, решает задачу по всем узлам. Под этим я имею в виду, что каждый узел будет получать уведомления от других 19 и будет обновлять модификации других 19. Такие настройки типа os устанавливаются?

Answer 1

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

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). Если вам нужно больше кеша, чем у вас на любом узле вашего кластера EhCached, полная репликация будет невозможна.
   • Или вы можете использовать кластер Redis или аналогичный независимо от вашего приложения и серверов, на которых работает ваше приложение. Это позволит вам масштабировать кеш с другой скоростью, чем остальная часть вашего приложения, однако доступ к данным не будет таким тривиальным.

Конечно фактическое решение зависит от очень конкретного сценария использования и требований вы кладете в вашем приложении.

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

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