Я хотел узнать, верны ли мои оценки и опасения.
Я некоторое время изучал три из них: службу распределения данных, AMQP и ZeroMQ для создания уровня передачи данных в центре обработки данных. Все три выглядят многообещающе, но у некоторых я столкнулся с некоторыми проблемами блокировки.
Чтобы дать контекст, мои требования:
- Масштабирование до 500+ физических узлов, 1000+ издателей и подписчиков.
- Поддерживайте надежную доставку сообщений, чтобы позаботиться об отказавших подписчиках.
- Совокупная пропускная способность должна быть выше 1 миллиона сообщений в секунду.
Проблемы с AMQP:
- Архитектура брокера кажется узким местом и центральной точкой отказа во всей настройке развертывания. Я могу усложнить свое развертывание, поставив федерацию и кластер для повышения производительности и доступности ожидающих сообщений, но они все равно не кажутся отказоустойчивыми.
- Производительность длительных очередей кажется очень низкой. Мое примерное приложение могло синхронизировать только 6-7K сообщений/ядра/очереди/приложения.
Проблемы с ZeroMQ:
- Документация, кажется, немного нуждается в глубине.
- Поведение системы для ожидающих сообщений, похоже, вызывает проблемы в модели связи PUB/SUB. См.: Как Zeromq обрабатывает медленных потребителей с PUB/SUB режим
OpenSplice DDS: я не нашел ничего плохого в протоколе DDS, за исключением принятия в отрасли. Хотелось бы узнать обзор этого продукта из первых рук с точки зрения стабильности, производительности или ограничений.
ZMQ_HWM: high water mark
иZMQ_SWAP: disk offload size
. Подробнее см. api.zeromq.org/master:zmq-getsockopt. - person Evgeniy Berezovsky   schedule 14.08.2012