Message Queue

[metaclass]

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

Comments

[juan-gandhi.livejournal.com]

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

[denisioru.livejournal.com]

Зачем изобретать велосипеды, есть MSMQ, есть MSSQL. Думаю, распределенные очереди есть и у других, не на платформе Microsoft.

[metaclass.livejournal.com]

Надо что-нибудь гуманное, размером с клиентскую библиотеку, а не тащить MSSQL на клиентские машины :)

[berezovsky.livejournal.com]

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

[denisioru.livejournal.com]

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

[sbj-ss.livejournal.com]

Да, мы пользовались симметричным вариантом "по очереди на клиенте и сервере". И там и там инстансы MSSQL с брокером, так что вопрос "кто ведущий, а кто ведомый" поднимался только на более высоком уровне абстракции - и ничего греховного в этом имхо нет.

[falcrum.livejournal.com]

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

[vinslivins.livejournal.com]

няяя

[plumqqz.livejournal.com]

Да, как-то так.

[romik-g.livejournal.com]

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

[1master.livejournal.com]

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

[avnik.livejournal.com]

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

[antilamer.livejournal.com]

At least once + транзакционность получателя = exactly once.

[themech.livejournal.com]

Смотрели aws sqs?

[avnik.livejournal.com]

дупит с неебическорй силой

[hahashi.livejournal.com]

+1
Visibility Timeout все решает
если я правильно понял проблему

[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]

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

[berezovsky.livejournal.com]

"Now they have two problems".

Однажды Онуфрий описывал очередь обработки. Освоил объекты, оглядел Оракл. Отладил операции, обрывы, ожидание. Обфусцировал, оформил окончательно. Одокументил окружение, обслуживание.

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

Оклемавшись, отправился одолевать Окамл. Однако! Очаровывает однозначно.

Опешил Онуфрий. Обдумал обновлённую, оригинальную очередь. Окамл, О'Рейли, отправка-обработка, одобрение-отклонение, от оно! Описал, отладил.

[metaclass.livejournal.com]

Да, к чему-то похожему мы и склоняемся.

[napishi.livejournal.com]

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

[inhate.livejournal.com]

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