DDS против AMQP против ZeroMQ

Я хотел узнать, верны ли мои оценки и опасения.

Я некоторое время изучал три из них: службу распределения данных, AMQP и ZeroMQ для создания уровня передачи данных в центре обработки данных. Все три выглядят многообещающе, но у некоторых я столкнулся с некоторыми проблемами блокировки.

Чтобы дать контекст, мои требования:

  1. Масштабирование до 500+ физических узлов, 1000+ издателей и подписчиков.
  2. Поддерживайте надежную доставку сообщений, чтобы позаботиться об отказавших подписчиках.
  3. Совокупная пропускная способность должна быть выше 1 миллиона сообщений в секунду.

Проблемы с AMQP:

  1. Архитектура брокера кажется узким местом и центральной точкой отказа во всей настройке развертывания. Я могу усложнить свое развертывание, поставив федерацию и кластер для повышения производительности и доступности ожидающих сообщений, но они все равно не кажутся отказоустойчивыми.
  2. Производительность длительных очередей кажется очень низкой. Мое примерное приложение могло синхронизировать только 6-7K сообщений/ядра/очереди/приложения.

Проблемы с ZeroMQ:

  1. Документация, кажется, немного нуждается в глубине.
  2. Поведение системы для ожидающих сообщений, похоже, вызывает проблемы в модели связи PUB/SUB. См.: Как Zeromq обрабатывает медленных потребителей с PUB/SUB режим

OpenSplice DDS: я не нашел ничего плохого в протоколе DDS, за исключением принятия в отрасли. Хотелось бы узнать обзор этого продукта из первых рук с точки зрения стабильности, производительности или ограничений.


person Kisalay    schedule 08.07.2010    source источник
comment
Я подробно рассмотрю ваш вопрос позже, но сейчас хочу предложить вам добавить тег data-distribution-service вместо dds. Последний, кажется, был захвачен графическим программированием.   -  person Holger Hoffstätte    schedule 09.07.2010
comment
Спасибо, Хольгер, обновил теги.   -  person Kisalay    schedule 10.07.2010
comment
Просто чтобы сделать связанное обсуждение ZeroMQ более тонким: для PUB/SUB действительно существует предварительно установленный предел для каждого подписчика на размер очереди сообщений, при превышении которого сообщения удаляются. Но есть также опция ZMQ_SWAP, с помощью которой вы можете включить обмен сообщениями на диске. Цитата [1] Однако выход есть. ØMQ предоставляет нечто, называемое ››swap‹‹, который представляет собой файл на диске, содержащий сообщения, которые мы не можем сохранить в очереди [1] zguide.zeromq.org/chapter:all   -  person ron    schedule 26.09.2010
comment
@Kisalay Что касается обработки медленных потребителей в ZeroMQ: последние версии позволяют настраивать ZMQ_HWM: high water mark и ZMQ_SWAP: disk offload size. Подробнее см. api.zeromq.org/master:zmq-getsockopt.   -  person Evgeniy Berezovsky    schedule 14.08.2012


Ответы (2)


Я удивлен вашим беспокойством по поводу принятия OpenSplice DDS. Сегодня OpenSplice DDS развернут в нескольких критически важных для бизнеса и миссии системах, таких как военно-морские боевые системы управления, военные транспортные средства, управление и управление воздушным движением, метро и высокочастотная автоматическая торговля. Просто чтобы дать вам еще немного информации, которая должна дать вам уверенность в том, что вы w.r.t. После принятия технологии стандарт OMG DDS (стандарт, реализованный OpenSplice DDS) был рекомендован EUROCAE для обмена планами полетных данных между панъевропейскими центрами.

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

-AC

person acor    schedule 20.08.2010
comment
Да, и я смотрел на код OpenSplice, и это ужасно. Кроме того, API — это большой беспорядок, и его сложно настроить. OpenSplice был написан людьми, которые ничего не понимают в принципах проектирования программного обеспечения. И это может быть принято многими компаниями, потому что это работает, но это точно не тот путь, если вы хотите развиваться в будущем. - person fonZ; 26.06.2014

Взгляните на эту страницу. Многие отрасли и компании сегодня используют DDS.

person Sumant    schedule 12.10.2012