Синхронизация сообщений BlazeDS на двух веб-серверах - PullRequest
0 голосов
/ 05 марта 2012

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

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

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

Ответы [ 2 ]

2 голосов
/ 06 марта 2012

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

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

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

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

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

1 голос
/ 05 марта 2012

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

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

Функции обмена сообщениями BlazeDS описаны здесь .Я все еще рекомендую первую версию (база данных).

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

...