Шина обмена сообщениями + хранилище событий + PubSub - PullRequest
4 голосов
/ 26 июня 2011

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

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

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

Я думал об использовании корпоративной шины обмена сообщениями JMS (например, Mule ) или корпоративной шины обмена сообщениями AMQP (например, RabbitMQ или ZeroMQ ).

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

Что будет работать лучше, CouchDB + масштабирование + балансировка нагрузки + какой-то механизм PubSub или явная система обмена сообщениями PubSub с подключенным в конечном итоге согласованным, доступным, устойчивым к разделам хранилищем?Какой из них легче настроить, администрировать и использовать?Какое решение будет иметь высокую пропускную способность для данной стоимости?Почему?

Кроме того, есть ли еще вопросы, которые я должен задать перед выбором своих технологий?(Кстати, Java - это язык на стороне сервера и на стороне клиента).

Ответы [ 3 ]

6 голосов
/ 27 июня 2011

Я использую очередь сообщений CouchDB в производстве. (Это не pub / sub, поэтому я не считаю этот ответ завершенным.)

В настоящее время (июнь 2011 г.) CouchDB обладает огромным потенциалом в качестве субстрата для обмена сообщениями:

  1. Хорошее сохранение данных
  2. Хорошо подготовлен для кластеризации (в локальной сети, используя BigCouch или Lounge)
  3. Хорошо подготовлено для распространения (между центрами обработки данных по всему миру)
  4. Хорошая платформа. Несмотря на перечисленные ниже недостатки, мне нравится CQS, потому что я могу повторно использовать свою БД, и она работает от Erlang, NodeJS и любого веб-браузера.
  5. Запрос _changes
    1. Непрерывная подача, мгновенная доставка без опроса
    2. Сеть не работает, просто повторите попытку позже с предыдущей позиции

Тем не менее, даже небольшая система сообщений в CouchDB требует тщательного планирования и обслуживания. CouchDB - это потенциально отличный сервер обмена сообщениями. (Он вдохновлен Lotus Notes, который обрабатывает большой объем электронной почты.)

Однако с CouchDB возникают следующие проблемы:

  1. Файлы баз данных только для добавления быстро растут
    1. Обратите внимание на емкость диска
    2. Будьте внимательны к дисковому вводу / выводу. Сжатие прочитает и перепишет все живые документы
  2. Удаленные документы на самом деле не удаляются. Они отмечены deleted=true и хранятся вечно даже после уплотнения! На самом деле это уникально хорошо для CouchDB, потому что действие deleted будет распространяться через кластер, даже если сеть отключится на некоторое время.
  3. Распространение (репликация) удалений - это прекрасно, но как насчет создания удаленных документов? В конце концов это превзойдет все остальное. Решение состоит в том, чтобы очистить их , что фактически удаляет их с диска. К сожалению, если вы выполните 2 или более чисток перед запросом карты / уменьшенного представления, представление полностью восстановит себя . Это может занять слишком много времени, в зависимости от ваших потребностей.

Как обычно, мы слышим, как базы данных NoSQL кричат ​​"бесплатный обед!", "Бесплатный обед!" в то время как CouchDB говорит: «Вам придется работать для этого».

К сожалению, если у вас нет непреодолимого давления для повторного использования CouchDB, я бы использовал специальную платформу обмена сообщениями. У меня был хороший опыт использования ejabberd в качестве платформы для обмена сообщениями и общения с / из Google App Engine.)

2 голосов
/ 10 июля 2011

Хотя вы можете использовать базу данных в качестве альтернативы системе очередей сообщений, ни одна база данных не является системой очередей сообщений, даже CouchDB. Система очередей сообщений, такая как AMQP, обеспечивает больше, чем просто постоянство сообщений, на самом деле с RabbitMQ постоянство - это невидимая скрытая служба, которая решает все проблемы, с которыми вам приходится сталкиваться самостоятельно на CouchDB.

Внимательно посмотрите на веб-сайт RabbitMQ, где есть много информации о AMQP и о том, как ее использовать. Они проделали большую работу по сбору статей и блогов об очередях сообщений.

2 голосов
/ 26 июня 2011

Я думаю, что лучшим решением будет CouchDB + сервер Jabber / XMPP (ejabberd) + book: http://professionalxmpp.com

  • JSON - это естественный механизм хранения для CouchDB
  • Сервер Jabber / XMPP включает поддержку pubsub
  • Книгу необходимо прочитать
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...