2015-08-06 2 views
1

Мы запускаем 4 экземпляра сервера tomcat в двух геолокациях с балансировщиком нагрузки на основе DNS. Мы предоставляем некоторые экспортные услуги, для выполнения которых требуется много времени. Таким образом, пользователь обычно отправляет запрос на один из наших серверов и отвечает за всю обработку.Сохранение информации о ходе работы в сеансовом компоненте

enter image description here

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

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

Другим решением, о котором я мог думать, является использование нашей базы данных MySQL для хранения такой информации, но я боюсь огромной перегрузки, вызванной постоянным обновлением информации о ходе.

Любые идеи для решения моей проблемы?

Спасибо заранее,

Михал

+0

Это не совсем ясно из вашего описания, но было бы целесообразно использовать весеннюю сессию для синхронизации сессий по контейнерам, а затем хранить ключ, чтобы получить информацию о ходе работы в этой сессии ? – chrylis

+0

Весенняя аутентификация используется совместно с Redis? Это законная вещь? –

+0

Что значит «много времени, чтобы закончить» именно? Если это меньше тайм-аута сеанса, возможно, липкие сеансы просто решают проблему? – cichystefan

ответ

0

ОК, я, наконец, решить мою проблему. Я много думал о сохранении информации о ходе работы в сеансе, которая не была доступна при обработке асинхронной задачи, и я полностью забыл, что это не очень хорошая идея :-)

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

redis-cli preview

Спасибо всем за комментарии!

С уважением,

Michal

Смежные вопросы