Имеется необходимость разработать middleware-модуль: сборщик/раздатчик сообщении, он же «message router», он же «message broker», он же «message orientated middleware». За громкими названиями в текущей реализации — простая суть: клиенты рассылают сообщения (асинхронно), сообщение доходит до broker’а (пока буду называть так требуемый сборщик/раздатчик), он его каким-то образом обрабатывает и придерживает до того момента, как его не запросит получатель сообщения (тот, кому оно предназначалось).
Получатель запрашивает сообщения, сообщения передаются получателю – всё на этом работа broker’а закончена.
Первая идея реализовать брокера – использовать для хранения память, была отвергнута, т.к. безответственный получатель, не забирающий данные, заставит брокера пожрать всю память.
Вторая – использовать БД для хранения сообщений – при «интенсивном» получателе будет постоянно генерировать запросы к БД.
Финальный (текущий) вариант – использование памяти для очередей ссылок на сообщения, которые хранятся в НЕ-SQL БД (из преимуществ – не требует настройки БД, из недостатков – недостаточно быстрый старт (считываются очереди сохраняемые в момент остановки) и чувствительность к штатной остановке (могут не записаться текущие очереди)).
Интересует вопрос, кто создавал подобные решения?
Требования простые:
малое потребление памяти
быстрый старт
возможность обрабатывать сообщения большого размера, при небольшом кол-ве самих сообщений
желательно отсутствие необходимости создавать БД
Т.к. требования достаточно противоречивы – выставлены в порядке убывания приоритета.
Так же интересует вопрос отдачи сообщений получателю – кто какие шаги использует (уведомления об обработке, периодический опрос, подписка на тип сообщений и пр….)
P.S.: Готовые программные продукты неподходят так как требуют дополнительных ресурсов, настройки и предполагают, что архитектура будет строится вокруг них, а для меня это просто средство создания асинхронного обмена сообщениями — возможно потом это будет объединено в 1 exe-файл.
My<cod/>.net
