Можно ли гарантировать, что сообщение было успешно доставлено в концентратор событий при его отправке с помощью политики log-to-eventhub в управлении API?
Изменить: в нашем решении мы не можем разрешить выполнение любого запроса, если сообщение не было доставлено в концентратор событий. Насколько я могу судить, политика log-to-eventhub не проверяет это.
Добро пожаловать в Stackoveflow!
Примечание. После передачи данных в концентратор событий они сохраняются и будут ждать, пока потребители концентратора событий их обработают. Концентратор событий не заботится о том, как он обрабатывается; он просто заботится о том, чтобы убедиться, что сообщение будет успешно доставлено.
Для получения дополнительных сведений см. «Зачем отправлять в концентратор событий Azure?».
Надеюсь это поможет.
Концентраторы событий построены на основе служебной шины. Согласно служебной шине документация,
При использовании любого из поддерживаемых клиентов API служебной шины операции отправки в служебную шину всегда устанавливаются явным образом, что означает, что операция API ожидает получения результата приема от служебной шины, а затем завершает операцию отправки.
Если сообщение отклоняется служебной шиной, отклонение содержит индикатор ошибки и текст с идентификатором отслеживания внутри него. Отклонение также включает информацию о том, можно ли повторить операцию с любой надеждой на успех. В клиенте эта информация преобразуется в исключение и передается вызывающей стороне операции отправки. Если сообщение было принято, операция завершается без вывода сообщений.
При использовании протокола AMQP, который является эксклюзивным протоколом для клиента .NET Standard и клиента Java и который является опцией для клиента .NET Framework, передача сообщений и расчеты являются конвейерными и полностью асинхронными, поэтому рекомендуется использовать варианты API модели асинхронного программирования.
Отправитель может быстро отправить несколько сообщений по сети, не дожидаясь подтверждения каждого сообщения, как это было бы в противном случае с протоколом SBMP или с HTTP 1.1. Эти операции асинхронной отправки завершаются по мере того, как соответствующие сообщения принимаются и сохраняются, на разделенных объектах или при наложении операций отправки на разные объекты. Завершение также может происходить из исходного заказа на отправку.
Я думаю, это означает, что SDK получает квитанцию о каждом сообщении.
Этой теории дополнительно способствует RetryPolicy Класс, используемый в Свойство ClientEntity.RetryPolicy Класс EventHubSender.
В управлении API раздел logging-to-eventhub, есть также раздел, посвященный интервалам повторов. Ниже приведены разделы, посвященные изменению ответа на возврат или выполнению действий с определенными кодами состояния. Как только коды состояния неудачной попытки регистрации станут известны, вы можете изменить политики, чтобы предпринимать действия при неудачных попытках регистрации.
