Очередь Azure-могу ли я проверить, что сообщение будет прочитано только один раз?

Я использую очередь Azure и имею несколько различных процессов, считывающих из очереди.
Моя система построена таким образом, что каждое сообщение читается только один раз.
Это статья Microsoft утверждает, что очереди Azure имеют хотя бы раз гарантия доставки, которая потенциально означает, что два процесса могут читать тот же сообщение из очереди.
Это поток StackOverflow утверждает, что если я использую GetMessage тогда сообщение становится невидимым для всех других процессов для отключения невидимости.

предполагая, что я использую GetMessage () и никогда не превышайте время невидимости сообщения до I DeleteMessage, могу ли я предположить, что я получу каждое сообщение только один раз?

3 ответов


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

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.cloudqueuemessage.dequeuecount.aspx (клиент хранения 1.7)

http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.windowsazure.storage.queue.cloudqueuemessage.dequeuecount.aspx (клиент хранения 2.0)


нет. Может произойти следующее:

  • GetMessage ()
  • добавить некоторые записи в базе данных...
  • создать некоторые файлы...
  • DeleteMessage () -> непредвиденный сбой (процесс, который аварийно завершает работу, экземпляр, который перезагружается, проблемы с сетевым подключением,...)

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

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

альтернативным решением было бы использовать очереди служебной шины с ReceiveAndDelete режим (см. этой страница под Как получать сообщения из очереди). Если вы получите сообщение, оно будет помечено как потребляемое и никогда не появится снова. Таким образом, вы можете быть уверены, что он доставлен В-Самый-Раз (см. сравнение с очередями хранения здесь). Но опять же, если что-то происходит во время обработки сообщения (т. е. сбои сервера, ...), вы можете потерять ценную информацию.

обновление:

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

  • GetMessage ()
  • DeleteMessage ()
  • AddRecordsToDatabase ()
  • GenerateFiles()

предполагая, что я использую GetMessage () и никогда не превышать время невидимости сообщения прежде чем я DeleteMessage, могу ли я предположить, что я получу каждое сообщение только один раз?

да.