Подходит ли JMS (или любое другое решение для обмена сообщениями) для последователя / следующей модели

Question

Ради простоты, давайте предположим, что я клонирую твиттер (а я нет). Таким образом, каждый пользователь может следовать за другими пользователями, и за ними могут следовать другие пользователи. За каждого подписчика вы получаете все твиты, которые он отправляет. Все хранится в хранилище данных (будь то решение NoSQL или сегментированная реляционная база данных).

Однако, когда пользователи находятся в сети , считаете ли вы целесообразным, чтобы они получали твиты через JMS, а не опрашивали базу данных и получали новые твиты:

• когда пользователь регистрируется (или когда он входит в систему), создается тема JMS, названная в его честь (или его идентификатор)
• когда пользователь входит в систему, он подписывается на тему JMS каждого из пользователей, за которыми он следует
• объект в рамках сеанса (для каждого пользователя) действует как прослушиватель сообщений JMS
• все полученные сообщения сохраняются в сеансе (в памяти)
• пользовательский интерфейс обновляется с помощью ajax-опроса объекта в области сеанса
• когда пользователь выходит из системы или его сеанс истекает, прослушиватель сообщений уничтожается

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

Все это, конечно, должно работать в кластере и быть масштабируемым.

Однако я не уверен:

• действительно ли это того стоит (с точки зрения увеличения производительности и масштабируемости)
• не добавляет ли JMS нежелательные накладные расходы, что равносильно запросу хранилища данных (и, следовательно, делает бесполезным все осложнение)

В какой-то момент (когда все работает) я сделаю несколько тестов, но я бы хотел услышать некоторые начальные замечания.

Answer 1

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

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

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

Поскольку в действительности он не управляется событиями, вы можете вместо этого рассмотреть распределенное хранилище данных в памяти, такое как EhCache + JGroups или JBossCache3 (что я настоятельно рекомендую). Новые твиты будут добавлены в этот распределенный магазин, и читатели должны будут просто перелистать их в поисках интересующих их предметов. Это может быть более эффективным с точки зрения памяти, поскольку на каждом узле будет храниться только одна копия каждого твита. Вы также можете предварительно загрузить кеш при запуске системы.

Answer 2

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

Одним из факторов является вопрос, что увидят ваши пользователи при следующем входе в систему:

1. Все твиты, которые не были доставлены пользователю в его предыдущих сеансах. Или
2. Все твиты, которые были опубликованы в предыдущие х часов.

Случай 1: JMS хорош, потому что очередь может запомнить, какие сообщения уже доставлены. Но подождите: это означает, что вам нужно иметь одну очередь на сообщение получатель .

Случай 2: Здесь вы можете по-настоящему работать с темами в сообщении отправитель , а также получать сообщения с истекшим сроком действия, превышающие x часов. Опять же, JMS может быть хорошим вариантом.

Производительность

Реализации JMS обычно могут хранить сообщения в памяти, и для доступа к сообщениям в очереди / теме вам не нужно искать в большом индексе - поэтому я предполагаю, что это должно быть быстрее, чем база данных, вероятно, все еще быстрее, чем база данных в памяти. В случае сбоя узла вы можете либо заново создать очереди из резервной базы данных, либо использовать high-Availability и Persistence , встроенные в некоторые реализации JMS.

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

Так что, возможно, я бы просто сохранил идентификаторы в очередях и поместил фактические сообщения в кеш объекта Java. Таким образом, вам снова придется использовать индекс, но вы получаете удобство от JMS с большей эффективностью использования памяти кеша объектов. Когда кеш находится только на стороне отправителя, его даже не нужно распределять, предполагая, что все сообщения от одного отправителя находятся на одном (реплицированном) узле, но это зависит, вероятно, от множества других архитектурных решений.