Запретить несколько экземпляров веб-задания Azure обрабатывать одно и то же сообщение очереди

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

  • Моя веб-работа относится к типу непрерывного выполнения.
  • Я использую QueueTrigger для получения сообщения и вызова функции
  • Моя функция работает несколько часов.

Я изучил свойства JobHostConfiguration.BatchSize и MaxDequeue, и я не уверен в них. Мне просто нужен единственный экземпляр, обрабатывающий сообщение, и это может занять несколько часов.

Это то, что я вижу в журналах веб-заданий, указывающих, что сообщение получено дважды.

[24.01.2017 16:17:30 ›7e0338: INFO] Выполнение: 'Functions.RunExperiment' - Причина: 'Новое сообщение очереди обнаружено в' runexperiment '.'

[24.01.2017 16:17:30 ›7e0338: INFO] Выполнение: 'Functions.RunExperiment' - Причина: 'Новое сообщение очереди обнаружено в' runexperiment '.'


person Arif    schedule 24.01.2017    source источник
comment
Не уверен, что это лучшее решение, но я решил проблему идемпотентности, проверив dequeueCount, чтобы узнать, запускать ли это или выйти. Я надеялся, что очередь сообщений по умолчанию или разрешит конфигурацию, чтобы предотвратить разветвление сообщения.   -  person Arif    schedule 25.01.2017
comment
Вы видели исключения? Когда выбрасываются исключения, сообщения игнорируются.   -  person Thomas    schedule 25.01.2017
comment
Никаких исключений не было. В журналах веб-заданий можно было увидеть два запущенных экземпляра, и они как завершали, так и дублировали работу.   -  person Arif    schedule 25.01.2017
comment
О, если для обработки сообщения требуется время, вам следует возобновить блокировку. вы можете использовать OnMessageOptions.AutoRenewTimeout. см. stackoverflow.com/a/33785389/4167200   -  person Thomas    schedule 25.01.2017


Ответы (2)


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

Триггер очереди SDK WebJobs автоматически предотвращает обработку функцией сообщения очереди несколько раз; функции не должны быть написаны для идемпотирования.

Я развернул WebJob на 2 экземплярах WebApp, он также работает правильно (не выполняется дважды с одним и тем же сообщением в очереди). Он может работать на двух экземплярах, и нет повторяющихся выполненных сообщений.

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

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

public static void ProcessQueueMessage([QueueTrigger("queue")] string message, [Queue("logqueue")] out string newMessage, TextWriter log)
    {
        string instance = Environment.GetEnvironmentVariable("WEBSITE_INSTANCE_ID");
        string newMsg = $"WEBSITE_INSTANCE_ID:{instance}, timestamp:{DateTime.Now}, Message:{message}";
        log.WriteLine(newMsg);
        Console.WriteLine(newMsg);
        newMessage = newMsg;
    }
}

введите описание изображения здесь

введите описание изображения здесь

person Tom Sun - MSFT    schedule 25.01.2017
comment
Я больше не могу это воспроизвести. В тот день, когда я разместил сообщение, я видел, как для одного и того же сообщения запускалось несколько вакансий. Я отмечу это как завершенное и буду внимательно следить, если увижу это снова. - person Arif; 27.01.2017
comment
Есть ли у вас обновления по этой теме? Если это полезно, помогите пометить его как ответ, который поможет большему количеству сообществ, у которых есть такая же проблема. - person Tom Sun - MSFT; 06.02.2017

У меня была одна и та же проблема с одним сообщением, обрабатываемым несколько раз одновременно. Проблема исчезла, как только я установил свойство MaxPollingInterval ...

person Loul G.    schedule 18.12.2017