Блог

У меня есть следующая функция Azure, запускаемая Http, для отправки данных в очередь. Но как я могу увидеть поведение, при котором служебная шина Azure не гарантирует порядок FIFO?

Я использую поведение приема с прищуром. Предполагая, что у меня есть сообщения 1,2,3,4 в очереди. Если мое приложение потерпело неудачу при получении сообщения 1, как реагирует функция Azure из-за ее параллелизма? Будет ли другой поток, который читает сообщение 2 во время тайм-аута сообщения 1?

         [FunctionName("ServiceBusFunction")]
        public static void Run([ServiceBusTrigger("testQueueDuplicateDetection")] string myQueueItem, ILogger log)
        {
            log.LogInformation($"C# ServiceBus queue trigger function processed message: {myQueueItem}");
        }

        [FunctionName("ServiceBusOutput")]
        [return: ServiceBus("testQueueDuplicateDetection")]
        public static string ServiceBusOutput([HttpTrigger] string input, ILogger log)
        {
            log.LogInformation($"C# function processed: {input}");
            return input;
        }
 

Заранее спасибо!

Но как я могу увидеть поведение, при котором служебная шина Azure не гарантирует порядок FIFO?

Служебная шина Azure допускает подход FIFO (Первый вход-Первый выход), мы не можем гарантировать, что сообщения вводятся в том порядке, в котором мы хотим, чтобы они обрабатывались процессом Подписчика.

Чтобы сделать это, нам нужно было бы пожертвовать многопоточным / многопроцессным способом ввода сообщений (Fan-In) и вместо этого использовать подход с одним издателем. Аналогичным образом, на стороне обработки сообщений мы не можем гарантировать потокобезопасный подход к обработке сообщений без использования подхода с одним Подписчиком, тем самым жертвуя преимуществами масштабируемости подхода с разветвлением.

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

Вы можете перейти по этой ссылке для получения дополнительной информации.

У меня в очереди есть сообщения 1,2,3,4. Если мое приложение потерпело неудачу при получении сообщения 1, как реагирует функция Azure из-за ее параллелизма? Будет ли другой поток, который читает сообщение 2 во время тайм-аута сообщения 1?

На основе документации azure среда выполнения функций получает сообщение в режиме скрытой блокировки. Он вызывает Complete сообщение, если функция успешно завершается, или вызывает Abandon , если функция завершается неудачно.

Если функция работает дольше PeekLock установленного времени ожидания, блокировка автоматически продлевается до тех пор, пока функция работает.