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]

няяя

[sbj-ss.livejournal.com]

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

[romik-g.livejournal.com]

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

[denisioru.livejournal.com]

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

[1master.livejournal.com]

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

[metaclass.livejournal.com]

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

[denisioru.livejournal.com]

Гуманное и распределенное? Вот чтото похожее?

[juan-gandhi.livejournal.com]

Особенно MSSQL хорош для репликации содержимого HBase.

Ваш паровод, MSMQ, не годится для вольного использования. Так что пошел-ка он. Вы, может, предложите и Эрланг выбросить, потому что есть сишарп?

[denisioru.livejournal.com]

Каждой задаче свой подход. Откуда мне знать, для чего у Вас эрланг и почему я должен предлагать выбросить сишарп?

[juan-gandhi.livejournal.com]

А зачем изобрели этот велосипед? Ведь есть уже MSMQ и MSSQL, куда уж лучше-то? Или MSMQ не распределенный? Так и зачем тогда вы его поминали?

[juan-gandhi.livejournal.com]

Вот.

[denisioru.livejournal.com]

потому на момент Вашего первого сообщения у меня не было информации о том, что тут эрланг как-то фигурирует.

[juan-gandhi.livejournal.com]

Где это "тут"? Я все написал на скале - но какая разница?

[metaclass.livejournal.com]

RabbitMQ (http://www.rabbitmq.com): It is developed using the Erlang programming platform (that is developed by Ericsson). You need to install Erlang first. I spent a lot of time to install, configure, and write a sample application. It has a .NET client but I got many errors when trying to develop and run a simple application. It was very hard to install and to make two rabbitMQ Brokers work together on two different servers. After a few days, I gave up because I thought it must not be that hard to learn and to start developing applications.

Если человек не осилил запустить кролика - его код использовать противопоказано.

[anonim-legion.livejournal.com]

У вас неприязнь к майкрософту?

[anonim-legion.livejournal.com]

LocalDb же есть, вроде.

[avnik.livejournal.com]

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

[avnik.livejournal.com]

оно иногда более головой, жрет всю доступную память и дохнет.
И это пример _как не надо писать на ерланге_

[themech.livejournal.com]

Смотрели aws sqs?

[avnik.livejournal.com]

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

[berezovsky.livejournal.com]

ебiческая сила