Message Queue
May. 24th, 2014 02:23 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassЧо-то я не совсем понимаю идеологию работы с сабжами в случае, когда нет гарантии работоспособности промежуточных узлов.
Вот например, есть кролик (rabbitmq), на сервере. В него какие-нибудь клиентские программы складывают данные на обработку специально обученными пауками. Теперь приходит белтелеком, крадет у нас связность между сервером и клиентом, или например, админ, которому не досталось личной ежихи в дурдоме - режет витую пару и плетет из нее макраме.
Соответственно, клиентская прога должна в это время копить сообщения для очереди в себе и дожидаться пока санитары повяжут админа и восстановят доступность сервера. Причем делать это корректно даже в том случае, если электрики решат, что именно сегодня надо отключить электропитание.
Но это ж ведь блин получается, что в клиентской библиотеке должна быть такая же очередь со всеми потрохами - персистентностью, каким-то внешним хранилищем для недоставленных мессаг и прочим таким. В итоге, вместо клиент-серверной модели мы получаем какую-то распределенную хрень, когда и на клиенте и на сервере стоят одинаковые сервера очередей и занимаются между собой греховной репликацией.
Внимание вопрос: а что из готовых решений в такое умеет? А то самодельные очереди СУБД немного задолбали, не говоря уже о том, что и СУБД может сдохнуть не вовремя, соответственно, складируемые в нее сообщения надо тоже складывать в какую-то очередь на этот случай.
Вот например, есть кролик (rabbitmq), на сервере. В него какие-нибудь клиентские программы складывают данные на обработку специально обученными пауками. Теперь приходит белтелеком, крадет у нас связность между сервером и клиентом, или например, админ, которому не досталось личной ежихи в дурдоме - режет витую пару и плетет из нее макраме.
Соответственно, клиентская прога должна в это время копить сообщения для очереди в себе и дожидаться пока санитары повяжут админа и восстановят доступность сервера. Причем делать это корректно даже в том случае, если электрики решат, что именно сегодня надо отключить электропитание.
Но это ж ведь блин получается, что в клиентской библиотеке должна быть такая же очередь со всеми потрохами - персистентностью, каким-то внешним хранилищем для недоставленных мессаг и прочим таким. В итоге, вместо клиент-серверной модели мы получаем какую-то распределенную хрень, когда и на клиенте и на сервере стоят одинаковые сервера очередей и занимаются между собой греховной репликацией.
Внимание вопрос: а что из готовых решений в такое умеет? А то самодельные очереди СУБД немного задолбали, не говоря уже о том, что и СУБД может сдохнуть не вовремя, соответственно, складируемые в нее сообщения надо тоже складывать в какую-то очередь на этот случай.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-05-24 07:50 am (UTC)Диванным теоретикам предлагаю описать алгоритм гарантированой доставки каждого сообщения в единственно мэкземпляре в условиях network parition (ага call me maybe -- это про это)
no subject
Date: 2014-05-24 05:44 pm (UTC)no subject
Date: 2014-05-24 08:11 pm (UTC)То есть вся отдача должна быть транзакционна, в пределах тех нод которые держат реплики.
Со стороны получателя требуется сказать ack или reject