Максимальный срок жизни сообщений очереди сообщений Azure составляет 7 дней. Почему? Я бы хотел, чтобы у моего сообщения было бесконечное время жизни и ожидание в очереди, пока я не обработаю его. Если бы не этот странный 7-дневный лимит, очереди Azure были бы для меня идеальным решением. У меня есть целая учетная запись хранения объемом 100 ТБ, поддерживающая мою очередь, почему я не могу ее использовать?
Я надеюсь, что у кого-то есть идея обходного пути или решения этой проблемы. Любые идеи?
Теперь вы можете выбрать бесконечный TTL, указав истечение -1 секунды, когда вы ставите сообщение в очередь. Это новое с API-версией 2017-07-29:
Для сервиса Queue API Put Message теперь допускает значение времени жизни в параметре messagettl более семи дней. Вы также можете указать -1 для этого параметра, чтобы указать, что сообщение должно оставаться в очереди до тех пор, пока оно не будет исключено из очереди и удалено. Значение по умолчанию для этого параметра по-прежнему равно семи дням.
Если вы застряли с более ранней версией библиотек хранилища Azure, я решил эту проблему, повторно поставив в очередь старые сообщения — когда им исполнилось 6 дней, я добавил дубликат в очередь и удалил оригинал.
Очереди служебной шины дают вам неограниченный TTL, как указывает Брайан.
Вы можете превысить ограничение в 5 ГБ, разделив несколько очередей SB. Однако мы обнаруживаем, что люди, достигшие этого предела, обычно находят и подходят к более полезному и экономичному подходу, когда любые большие элементы данных, которые у них есть, помещаются в хранилище (например, BLOB-объекты), а в очередь помещаются только задания, связанные с ними.
Это позволит вам использовать способность хранилища выполнять блочную загрузку (с блочными BLOB-объектами), а затем сообщать о наличии этого BLOB-объекта через очередь SB. После того, как вы обработали задание, вы можете удалить данные.
Существует не так много распространенных случаев использования, когда очередь превышает ограничение в 5 ГБ, и такой шаблон не является лучшим выбором в целом.
Вы можете посмотреть Очереди служебной шины. Я не очень хорошо с ними знаком, но в некоторых случаях они более гибкие, чем очереди хранения. Вы также можете рассмотреть другие системы очередей (MSMQ, RabbitMQ и т. д.), но они, вероятно, не стоят усилий по настройке в Azure.
Другой вариант — использовать таблицу хранения в качестве очереди. Затем вы можете поддерживать любой TTL, который вам нравится. Есть некоторые обсуждение этого здесь. Я действительно реализовал эту систему, и она отлично работает. Если у меня будет возможность, я постараюсь опубликовать код.
Я думаю, что 7-дневный лимит, на который вы ссылаетесь, - это задержка видимости (т.е. время, в течение которого сообщение будет невидимым)
Для времени жизни (указывает, как долго сообщение будет оставаться в очереди) не существует документированного ограничения, о котором я знаю (пожалуйста, укажите мне ссылку, если это не так)
Я основываю свой комментарий на следующей странице http://msdn.microsoft.com/en-us/library/windowsazure/hh563575.aspx
Надеюсь это поможет
