Управление прилипшими сессиями
Например, как показано на следующем рисунке:Независимый сеанс сервера требует пользователей на запросы сервера приложений должны работать на одном и том же вышеперечисленном выше, что требует сервера балансировки нагрузки каждый раз, когда пользователь отправляет запрос на сервер в верхней части одного и того же адреса.
Первый сервер, который я впервые посетил. Вся сессия пользователя должна быть загружена с сервера балансировки нагрузки на вершину сервера.
Другие серверы не будут сохранять информацию о сеансе пользователя №1.
Сегодняшние серверы балансировки нагрузки обычно имеют эту функцию (nginx).
Но предположим следующее
В это время, когда сервер № 1 не работает, сервер балансировки нагрузки перенаправит пользователя № 1 на сервер № 2 или № 3, но у пользователя нет безопасного контекста на серверах № 2 и 3. Сервера №3. Сервер уведомит пользователя о необходимости повторного входа в систему. Это определенно повлияет на пользовательский опыт. И очень вероятно, что это приведет к потере пользовательских данных.
Управление режимом репликации сеанса (т.е. репликация сеанса)
Каждый сервер сохраняет фактический сеанс пользователя, который связан с проблемой синхронизации сеанса между серверами приложений. Требования в реальном времени относительно высоки.
Этот метод может избежать проблем, с которыми сталкивается вышеупомянутый независимый от сервера сеанс, как показано на следующем рисунке:
Сильные стороны
Таким образом, даже при возникновении первой ситуации информация сеанса №1 сохраняется на серверах №2 и №3. При возникновении сбоя сервер балансировки нагрузки перенаправляет пользователя №1 на серверы №2 и 3. Сервер также обнаружит наличие контекста безопасности пользователя № 1 и сможет продолжить доступ без повторного входа в систему.
недостаток
Однако у этого метода также есть недостатки, то есть требования к синхронизации сеансов соответствующего сервера в реальном времени относительно высоки, и это приведет к дополнительным межполосным накладным расходам. И когда расстояние сеанса изменяется, его необходимо синхронизировать. Предположим, что количество информации в сеансе относительно велико. Это заняло бы довольно много памяти.
Централизованное управление кешем
Сервер делится информацией о сеансе:
Сильные стороны
Информация о сеансе каждого пользователя будет храниться на другом сервере вне приложения (возможно, в базе данных или службе хранения KV), так что серверу приложений не нужно хранить информацию о сеансе каждого пользователя, что экономит много денег. накладные расходы памяти.
Когда разным серверам приложений необходимо использовать информацию сеанса, они обращаются к общему серверу сеансов для получения информации.
Таким образом, серверу балансировки нагрузки не нужно назначать пользователей одному серверу и не нужно копировать информацию о сеансе между серверами.При изменении информации о сеансе все серверы приложений могут совместно использовать информацию об изменении сервера.
недостаток
Это больше зависит от общего сервера, если общий сервер или кластер общих серверов выходит из строя. Пользователи будут сильно затронуты