Message Queue

[metaclass]

Чо-то я не совсем понимаю идеологию работы с сабжами в случае, когда нет гарантии работоспособности промежуточных узлов.
Вот например, есть кролик (rabbitmq), на сервере. В него какие-нибудь клиентские программы складывают данные на обработку специально обученными пауками. Теперь приходит белтелеком, крадет у нас связность между сервером и клиентом, или например, админ, которому не досталось личной ежихи в дурдоме - режет витую пару и плетет из нее макраме.
Соответственно, клиентская прога должна в это время копить сообщения для очереди в себе и дожидаться пока санитары повяжут админа и восстановят доступность сервера. Причем делать это корректно даже в том случае, если электрики решат, что именно сегодня надо отключить электропитание.
Но это ж ведь блин получается, что в клиентской библиотеке должна быть такая же очередь со всеми потрохами - персистентностью, каким-то внешним хранилищем для недоставленных мессаг и прочим таким. В итоге, вместо клиент-серверной модели мы получаем какую-то распределенную хрень, когда и на клиенте и на сервере стоят одинаковые сервера очередей и занимаются между собой греховной репликацией.
Внимание вопрос: а что из готовых решений в такое умеет? А то самодельные очереди СУБД немного задолбали, не говоря уже о том, что и СУБД может сдохнуть не вовремя, соответственно, складируемые в нее сообщения надо тоже складывать в какую-то очередь на этот случай.

Comments

[juan-gandhi.livejournal.com]

Старая песня. Ну воти фидо умело. Я по образу и подобию фидо в 11-м году такое делал в одной полоумной конторе; они там не оценили мою policy-based replication. Сейчас эту контору хозяева закрывают; жаль, концов теперь не найти. Но в принципе фигня; ну вот журнал, HBase ведь доступна в сорсах. Имплементировать это более прилично (у них там проблемы) - и все.

[berezovsky.livejournal.com]

msmq же было вроде, в одной известной Корпорации на одном интересном проекте пользовали, и оно даже само после восстановления связи старые сообщения подхватывало
сейчас, наверное, в дотнетовской обёртке что-то такое должно быть

[denisioru.livejournal.com]

Ну в случае распределенной работы - да, очереди живут и на клиенте и на сервере. В Server Broker в MSSQL даже локально всегда работа идет по цепочке "очередь клиента -> очередь обработчика". И в силу этого достаточно ненапряжно можно переключить очередь обработчика на ремотный сервер.

[falcrum.livejournal.com]

Либо клиентская прога должна сказать: "Абзац, сервер недоступен, работать не буду" - самый частый вариант.

[vinslivins.livejournal.com]

няяя

[romik-g.livejournal.com]

Подразумевается высокая доступность для MQ сервиса и его близкое расположение к клиентам. И, как сказал falcrum, приложение должно уметь корректно откидывать ласты, если MQ не доступен.

[1master.livejournal.com]

Народ что-то подобное на transactional replication ваяет, временами с обвязкой из service broker. Но подробностей я не знаю, увы.

[avnik.livejournal.com]

проблема одна -- все умеют либо доставку _минимум одного_ сообщения, либо гарантию отсуствия дубликатов. ИЛИ-ИЛИ.
Диванным теоретикам предлагаю описать алгоритм гарантированой доставки каждого сообщения в единственно мэкземпляре в условиях network parition (ага call me maybe -- это про это)

[themech.livejournal.com]

Смотрели aws sqs?

[click0.livejournal.com]

Berkeley DB ?

[blackyblack.livejournal.com]

Для начала, нужно выяснить, так ли нужна персистеность на клиенте. Если правда нужна, то можно поискать какую-нибудь persistent queue реализацию.
Через СУБД делать не стоит - это уродское решение. Однако хорошее решение навскидку не скажу.

[golikov konstantine (from livejournal.com)]

Scribe от фейсбука:

If a scribe instance on a client machine (we’ll call it a resender for the moment) is unable to send messages to the central scribe server it saves them on local disk, then sends them when the central server or network recovers.

[hshhhhh.livejournal.com]

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

[napishi.livejournal.com]

Если клиенты виндовые, то я бы использовал (и использовал уже) родной MSMQ.
Он идёт в поставке, начиная с XP, имеет хорошую поддержку в .NET

[inhate.livejournal.com]

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