сообщения шаблоны очередей

Question

У нас есть две части архитектуры. По сути они образуют производителя и потребителя. Piece 1 (p1) публикует сообщения на Piece 2 (p2), которые обрабатывают сообщение, этот процесс включает отправку сообщения на удаленный узел, который должен вызывать сообщение после его обработки, этот процесс может занять несколько секунд в лучшем случае.

p2 имеет конечную длину в своей очереди, и элементы не удаляются до тех пор, пока они не получат сигнал от удаленного узла. Из-за этого p2 может вернуть ответ QUEUE_FULL на p1. Когда p1 получает этот ответ, он сохраняет очередь, всякий раз, когда создается новое сообщение, он добавляет его в конец этой очереди, а затем циклически переходит в очередь, отправляя сообщения на p2, пока он снова не получит QUEUE_FULL. Проблема здесь в том, что после того, как очередь p2 пуста/имеет место, она не может уведомить p1 для получения сообщений.

Для каждого экземпляра производителя в p2 существует соответствующий производитель в p1, это важно, когда речь идет о потенциальных решениях ниже.

Одним из решений может быть изменение p2, чтобы уведомить p1, когда в его очереди есть место, однако для этого решения требуется достаточное количество сетевых издержек (http), поскольку в любое время возможно много тысяч очередей p2 необходимо уведомить своих соответствующих производителей p1.

Другим решением может быть то, что p1 можно изменить, чтобы продолжить отправку сообщения на p2. Проблема в том, что у производителя в p1 должен быть поток, который спит x, прежде чем пытаться отправить следующее сообщение, ясно, что может быть один синглтон, который обрабатывает этот механизм сна/повтора, но логика здесь, поскольку производители и потребители увеличиваются до многие тысячи, становится довольно сложным;

• синхронизация на добавление, удаление, производители
• чтение очереди, делая следующий раз прочитать
• соображения для герметичного зацикливания при низком производителе счета
• соображения долго ждать, когда высокий производителя граф
• .. .. и т. д.

Я близок к предложению уровня MQ, где p1 публикует и читает p2. Однако это вводит новую проблему, когда p2 не может уведомить p1, когда удаленный узел уходит, однако это может быть обработано http-обратным вызовом от p2 до p1 - уровень накладных расходов здесь приемлем, поскольку вероятность того, что удаленный узел будет удален низкий.

Я пропустил шаблон дизайна, который бы устранил необходимость в MQ (еще одна услуга, о которой нужно беспокоиться, монитор и т. Д.)? Мысли очень ценились.

Некоторые другие детали: экземпляр производителя

• каждый p1 является запрос областью действия по большей части
• каждый p2 потребитель выделенному выполняющегося потока

Answer 1

Майк,

Похоже, что процесс имеет значительное количество сложности (с возможностью введения более) просто избегать использования MQ? Может быть много причин НЕ использовать MQ, стоимость моего опыта, но если у вас есть доступ к нему, используйте его с диким отказом! :) Его гораздо проще отслеживать новый процесс MQ, чем писать код для введения подобных возможностей.

В идеале надежная очередь предотвратила бы P1, когда-либо действительно нуждающуюся в информации о P2, или ее состоянии.

MQ также должен действительно смягчить необходимость того, чтобы P2 уведомлял P1 о том, что его удаленный узел опустился - P1 может продолжать получать сообщения о очереди в P2 (в зависимости от частоты сообщений/размера/ограничений хранения). Если удаленный узел опустился на значительное количество времени, то, надеюсь, это было запланированное событие, и операторы могут отключить P1. Административный канал между P2 и P1 звучит неплохо?

Он также вводит дополнительную сложность - вы знаете свою среду, но это может привести к таким вопросам, как «почему я больше не получаю сообщения?» - оказывается, что служба автономно завершает работу другой службы. Совершенно верно, это потрясающе и облегчает поддержку операторам - сделано неправильно, это просто увеличивает нагрузку на поддержку. Никто не любит этого парня.

Можете ли вы также поставить очередь на уровне данных, где хранилище для P2 может не быть проблемой?

Embrace the queue (MQ, MSMQ, Sql Queue)!

Z

Answer 2

Обзор 3 возможность

• Как насчет открытия еще одного MQ для служебных команд (вместо http invocations);
• считать p2 многопоточным, где один поток без ожидания извлекает сообщения из MQ и помещает их в другой поток для обработки;
• (!) Использовать транзакционную версию MQ - поэтому p2 может мгновенно извлекать сообщения, а p1 может поместить его как можно быстрее. Но если обработка завершится неудачно, очередь будет отброшена.