Почему подписки на таблицы событий Azure отправляют дубликаты событий с разными идентификаторами?
Я настроил подписку на сетку событий, чтобы инициировать вызов веб-ловушки для событий в группе ресурсов при создании ресурса.
Вызов веб-перехвата успешно обработан, и я возвращаю 200. Чтобы поддерживать идемпотентность, я сохраняю все события, произошедшие в таблице веб-перехватов, с идентификатором события и проверяю все входящие события, чтобы увидеть, существуют ли они в этой таблице.
Это проблематично для меня, потому что я получаю одно и то же событие несколько раз с разными идентификаторами. Я отправил его через проверку различий и подтвердил, что единственными различиями между событиями являются их eventTime и их идентификатор (но это касается одного и того же события, Microsoft.Resources.ResourceWriteSuccess в базе данных SQL).
Есть ли причина, по которой Event Grid отправляет мне одно и то же событие несколько раз с разными идентификаторами?
0 ответов
Так реализован EventGrid, если вы посмотрите документацию
Если конечная точка отвечает в течение 3 минут, Сетка событий попытается удалить событие из очереди повторов в максимально возможной степени, но дубликаты все равно могут быть получены.
вы можете использовать внутренний код для очистки журналов и сохраненных данных, используя идентификаторы событий и сообщений для выявления дубликатов.
В id Поле фактически является уникальным для каждого события и остается идентичным между повторными попытками и поэтому может использоваться для дедупликации.
Вы столкнулись с конкретной проблемой, связанной с некоторыми событиями, создаваемыми Azure Resource Manager (ARM). В частности, два события, которые вы видите, на самом деле являются отдельными событиями, а не дубликатами, генерируемыми ARM на разных этапах творческого потока для некоторых типов ресурсов.
ARM действует как входная дверь API для различных служб Azure и генерирует набор событий, которые являются обобщенными, и часто для получения подробностей о том, что произошло, вам нужно заглянуть в полезную нагрузку данных. Например, ARM будет генерировать событие успеха для каждого кода состояния 2xx, который он получает от службы Azure, поэтому 202 принято и 201 создано может привести к отправке двух событий, и единственный способ увидеть разницу будет в полезной нагрузке данных..
Это известная проблема, и мы работаем над тем, чтобы генерировать больше событий с высокой точностью, которые будут более четкими и на которые будет легче реагировать в этих сценариях. Идеальное состояние - это своего рода лента изменений для плоскости управления Azure.