Сборщик/раздатчик сообщении, он же «message broker»?

Question

[Федор Малышкин]

Имеется необходимость разработать middleware-модуль: сборщик/раздатчик сообщении, он же «message router», он же «message broker», он же «message orientated middleware». За громкими названиями в текущей реализации — простая суть: клиенты рассылают сообщения (асинхронно), сообщение доходит до broker’а (пока буду называть так требуемый сборщик/раздатчик), он его каким-то образом обрабатывает и придерживает до того момента, как его не запросит получатель сообщения (тот, кому оно предназначалось).

Получатель запрашивает сообщения, сообщения передаются получателю – всё на этом работа broker’а закончена.



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



Вторая – использовать БД для хранения сообщений – при «интенсивном» получателе будет постоянно генерировать запросы к БД.

Финальный (текущий) вариант – использование памяти для очередей ссылок на сообщения, которые хранятся в НЕ-SQL БД (из преимуществ – не требует настройки БД, из недостатков – недостаточно быстрый старт (считываются очереди сохраняемые в момент остановки) и чувствительность к штатной остановке (могут не записаться текущие очереди)).



Интересует вопрос, кто создавал подобные решения?

Требования простые:

1. малое потребление памяти
   
2. быстрый старт
   
3. возможность обрабатывать сообщения большого размера, при небольшом кол-ве самих сообщений
   
4. желательно отсутствие необходимости создавать БД
   

Т.к. требования достаточно противоречивы – выставлены в порядке убывания приоритета.



Так же интересует вопрос отдачи сообщений получателю – кто какие шаги использует (уведомления об обработке, периодический опрос, подписка на тип сообщений и пр….)



P.S.: Готовые программные продукты неподходят так как требуют дополнительных ресурсов, настройки и предполагают, что архитектура будет строится вокруг них, а для меня это просто средство создания асинхронного обмена сообщениями — возможно потом это будет объединено в 1 exe-файл.

Answer 1

[casey]

Redis, publish/subscribe?

Comments

[Виктор Логин]

А если у нас несколько серверов, то как слушать Redis? На одно сообщение отреагирует каждый сервер подписанный на канал, как этого можно избежать?

Answer 2

[BasilioCat]

beanstalkd — то, что вам нужно