Постановка Windows Azure ‹--› производство, вызывающее конфликты и ошибки в хранилище таблиц

Вы явно ошибаетесь в обработке двойных сообщений. Тот факт, что ваш идентификатор уникален, не означает, что сообщение не будет обрабатываться дважды в некоторых случаях, например:

1. Роль умирает и с частично завершенной работой, поэтому сообщение снова появится для обработки в очереди.
2. Неожиданный сбой роли, поэтому сообщение снова попадает в очередь.
3. FC переносит вашу роль, и у вас нет кода для обработки этой ситуации, поэтому сообщение снова попадает в очередь.

Во всех случаях вам нужен код, который обрабатывает тот факт, что сообщение появится снова. Один из способов - использовать DequeueCount и проверьте, сколько раз сообщение было удалено из очереди и получено для обработки. Убедитесь, что у вас есть код, который обрабатывает частичную обработку сообщения.

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

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

Есть несколько возможных причин:

Как вы читаете сообщения в очереди? Если вы выполняете Peek Message, сообщение будет по-прежнему видимым для другого экземпляра роли (или вашей промежуточной среды) до того, как сообщение будет удалено. Убедитесь, что вы используете функцию «Получить сообщение», чтобы сообщение было невидимым до тех пор, пока его нельзя будет удалить.

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

Эта проблема почти наверняка не имеет ничего общего с Staging vs Production, но, скорее всего, вызвана тем, что несколько экземпляров читают из одной очереди. Вероятно, вы можете воспроизвести ту же проблему, указав 2 экземпляра, или развернув один и тот же код в 2 разных производственных службах, или запустив код локально на своем компьютере разработчика (все еще указывающий на хранилище Azure) с использованием 2 экземпляров.

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

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

Как предполагали другие, причины могут быть

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

Не глядя на код, я предполагаю, что имеет место вариант 3 или 4.

Если вы не можете обнаружить проблему с помощью обзора кода, вы можете подумать о добавлении журнала на основе времени и обертки try / catch, чтобы лучше понять.

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

Добавлено 24 февраля

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

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

Итак, суть в том, чтобы быть идемпотентным. Вы можете попробовать использовать функцию обновления (обновления или вставки) хранилища таблиц, чтобы избежать появления ошибки EntitiyAlreadyExists, если это работает для вашего кода. Если все, что вы делаете, это вставляете новые сущности в хранилище таблиц Azure, то обновление должно решить вашу проблему с минимальным изменением кода.

Если вы делаете обновления, то это совсем другая игра с мячом. Один из способов состоит в том, чтобы объединить обновления с фиктивными вставками в одну таблицу с одним и тем же ключом раздела, чтобы исключить ошибку, если обновление произошло ранее, и пропустить обновление. Позже после удаления сообщения вы можете удалить фиктивные вставки. Однако все это добавляет сложности, поэтому гораздо лучше пересмотреть архитектуру продукта; например, вам действительно нужно вставлять / обновлять столько таблиц?

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

var queueMessage = GetNextMessageFromQueue();    

Foo myFoo = GetFooFromTableStorage(queueMessage.FooId);

if (myFoo == null)
{
    myFoo = new Foo {
                        PartitionKey = queueMessage.FooId
                    };

    AddFooToTableStorage(myFoo);
}

DeleteMessageFromQueue(queueMessage);

Если у вас есть два соседних сообщения в очереди с одинаковым FooId, вполне вероятно, что оба экземпляра будут проверять, существует ли Foo, но не найдут его, а затем попытаются его создать. Какой бы экземпляр ни попытался сохранить элемент последним, вы получите ошибку «Сущность уже существует». Поскольку он содержит ошибку, он никогда не попадает в часть кода с сообщением об удалении и поэтому через некоторое время становится видимым в очереди.

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

Обновление 27/02. Если это не последующие сообщения (которые, исходя из вашей схемы ключей раздела / строки, я бы сказал, что это маловероятно), то моя следующая ставка будет заключаться в том, что это же сообщение снова появится в очереди после таймаут видимости. По умолчанию, если вы используете .GetMessage (), время ожидания составляет 30 секунд. Он имеет перегрузку, которая позволяет указать, как долго этот временной интервал . Также существует функция .UpdateMessage (), который позволяет вам обновлять этот тайм-аут по мере обработки сообщения. Например, вы можете установить начальную видимость на 1 минуту, а затем, если вы все еще обрабатываете сообщение через 50 секунд, продлите его еще на минуту.