![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Message Queue
Чо-то я не совсем понимаю идеологию работы с сабжами в случае, когда нет гарантии работоспособности промежуточных узлов.
Вот например, есть кролик (rabbitmq), на сервере. В него какие-нибудь клиентские программы складывают данные на обработку специально обученными пауками. Теперь приходит белтелеком, крадет у нас связность между сервером и клиентом, или например, админ, которому не досталось личной ежихи в дурдоме - режет витую пару и плетет из нее макраме.
Соответственно, клиентская прога должна в это время копить сообщения для очереди в себе и дожидаться пока санитары повяжут админа и восстановят доступность сервера. Причем делать это корректно даже в том случае, если электрики решат, что именно сегодня надо отключить электропитание.
Но это ж ведь блин получается, что в клиентской библиотеке должна быть такая же очередь со всеми потрохами - персистентностью, каким-то внешним хранилищем для недоставленных мессаг и прочим таким. В итоге, вместо клиент-серверной модели мы получаем какую-то распределенную хрень, когда и на клиенте и на сервере стоят одинаковые сервера очередей и занимаются между собой греховной репликацией.
Внимание вопрос: а что из готовых решений в такое умеет? А то самодельные очереди СУБД немного задолбали, не говоря уже о том, что и СУБД может сдохнуть не вовремя, соответственно, складируемые в нее сообщения надо тоже складывать в какую-то очередь на этот случай.
Вот например, есть кролик (rabbitmq), на сервере. В него какие-нибудь клиентские программы складывают данные на обработку специально обученными пауками. Теперь приходит белтелеком, крадет у нас связность между сервером и клиентом, или например, админ, которому не досталось личной ежихи в дурдоме - режет витую пару и плетет из нее макраме.
Соответственно, клиентская прога должна в это время копить сообщения для очереди в себе и дожидаться пока санитары повяжут админа и восстановят доступность сервера. Причем делать это корректно даже в том случае, если электрики решат, что именно сегодня надо отключить электропитание.
Но это ж ведь блин получается, что в клиентской библиотеке должна быть такая же очередь со всеми потрохами - персистентностью, каким-то внешним хранилищем для недоставленных мессаг и прочим таким. В итоге, вместо клиент-серверной модели мы получаем какую-то распределенную хрень, когда и на клиенте и на сервере стоят одинаковые сервера очередей и занимаются между собой греховной репликацией.
Внимание вопрос: а что из готовых решений в такое умеет? А то самодельные очереди СУБД немного задолбали, не говоря уже о том, что и СУБД может сдохнуть не вовремя, соответственно, складируемые в нее сообщения надо тоже складывать в какую-то очередь на этот случай.
no subject
Однажды Онуфрий описывал очередь обработки. Освоил объекты, оглядел Оракл. Отладил операции, обрывы, ожидание. Обфусцировал, оформил окончательно. Одокументил окружение, обслуживание.
Очередь обработки оголтело отколбасила около осьми оборотов. Отключившись, околела окаянная. Огорчился Онуфрий. Откупорил, опрокинул, откусил окорок, окосел.
Оклемавшись, отправился одолевать Окамл. Однако! Очаровывает однозначно.
Опешил Онуфрий. Обдумал обновлённую, оригинальную очередь. Окамл, О'Рейли, отправка-обработка, одобрение-отклонение, от оно! Описал, отладил.
no subject
1) очередь на генераторе
2) оригинальная очередь
3) локальная очередь на клиенте
3.1) или много локальных очередей на многих клиентах
no subject
Вы придумали?
no subject
no subject