Синхронизация сообщений BlazeDS на двух веб-серверах

Question

У меня есть система Flex/BlazeDS webapp (псевдоконтентная система управления) с бэкэнд Java, работающая на 2 серверах WebLogic 10.3 для балансировки нагрузки и целей HA.

В основном, я использую опрос AMF для обновления моего приложения, так что, когда пользователь открывает документ из результатов поиска, соответствующая строка будет отображать заблокированный значок на всех пользовательских дисплеях, которые в настоящее время имеют этот документ на экране.

Проблема заключается в том, что если пользователь, подключенный к серверу A, открывает документ X, значок заблокирован будет отображаться только на экранах других пользователей, подключенных к серверу A. Отображения пользователей, подключенных к серверу B, не будут обновлено. Существует ли установленная парадигма или передовая практика для обеспечения того, чтобы заблокированное обновление распространялось на всех серверах?

Answer 1

Самый простой способ - использовать заблокированную базу данных (если вы уже используете базу данных в своем приложении).

Другим решением является реализация сценария издателя/подписчика и использование функции кластеризации BlazeDS, описанной here. Используя JGroups, BlazeDS можно настроить для работы в кластере, и сообщение, созданное издателем (заблокировать документ), будет распространено среди всех издателей.

Описаны функции обмена сообщениями BlazeDS here. Я по-прежнему рекомендую первую версию (базу данных).

Для более «экзотических» вариантов вы можете попробовать с ZooKeeper, Hazelcast и т. Д. Однако я бы не использовал их в вашем случае.

Answer 2

Я бы рекомендовал использовать блокировку базы данных (вам нужен только логический флаг и чистая транзакционная изоляция) и распределенная тема JMS для отправки события блокировки всем другим пользователям. Я не знаю, как и как вы можете сделать это с BlazeDS, но было бы легко настроить такую ​​архитектуру с помощью GraniteDS.

В принципе, когда пользователь запрашивает документ, транзакционный серверный компонент (скажем, EJB3) должен проверить, доступен ли ресурс, заблокировать его и опубликовать событие блокировки в распределенной теме JMS. Поскольку тема распределена, сообщение будет отправлено через все ваши узлы WebLogic, и все подключенные пользователи, независимо от того, к какому узлу кластера подключены, будут проинформированы об этом событии через пользователей с длинным опросом. GraniteDS имеет хорошую поддержку асинхронных сервлетов WebLogic (см. GravityWebLogicServlet), и это даст вашим пользователям гораздо больше в режиме реального времени, чем при простом опросе, и без ущерба для масштабируемости (асинхронные сервлеты предназначены для использования в таких настройках) ,

Некоторые дополнительные ресурсы:

• в режиме реального времени обмена сообщениями documentation для GraniteDS.
• Краткая информация video о кластеризации GraniteDS, функции HA и обмена сообщениями в реальном времени (хотя с JBoss и базовым чат-приложением).

Даже если вы не хотите или не можете использовать GraniteDS в своем проекте, я бы рекомендовал рассмотреть эту распространенную тему JMS, которая содержит лучшее и надежное решение вашей проблемы.