Возможно, вы не понимаете, какую неудачу вы пытаетесь решить. Если я правильно понимаю ваш сценарий, у вас есть подписка на аудит и подписка на обработку, подписанные и «Тема события». Это означает, что у вас будет два логических пользователя: один для аудита и один для обработки (я говорю логично, потому что каждый потребитель может иметь несколько экземпляров, читающих одну и ту же подписку для пропускной способности и избыточности).
Если вы используете PeekLock (по умолчанию) в качестве режима приема на вашем подписчивом клиенте, это означает, что если при записи сообщения аудита или обработки события появляется сообщение об ошибке или исключении, сообщение будет в конечном итоге появляться обрабатывается другим экземпляром-потребителем. Это предполагает, что Complete не был вызван из-за исключения. Теоретически, если ваши аудиторские и процессинговые потребители делают идемпотентные операции, тогда даже если ваши потребители потерпят неудачу, они могут уловить резервную копию, когда они вернутся в сеть, и никакие сообщения не будут пропущены, хотя некоторые могут получить более одного раза. Это не изменяется, если вы запускаете несколько экземпляров каждого пользователя, как вы сказали выше. Наличие нескольких экземпляров каждого выполняемого пользователя уменьшает количество возможного времени простоя, но вы не должны пропускать никаких сообщений, даже если у вас есть одна обработка экземпляра. Подписка будет продолжаться до тех пор, пока потребители не вернутся.
Если вы использовали режим приема RecieveAndDelete, у вас есть возможность потерять сообщения. Вот отличная статья о Best Practices for Performance Improvements Using Service Bus Brokered Messaging. Прочтите это.
Существует множество вариантов развертывания, основанных на ресурсоемкости операций аудита и обработки. У вас может быть рабочая роль или процесс, который обрабатывает как аудит, так и обработку сообщений на разных потоках в качестве пары и развертывает несколько экземпляров. Это означало бы, что каждый экземпляр может обрабатывать оба типа сообщений, но есть избыточность в том, что, если одна из машин работает, другой исполняемый экземпляр может продолжать обрабатывать.
Вам нужно будет проверять мертвые сообщения (например, ядовитые сообщения), а также те сообщения, которые не обрабатывались или, возможно, не полностью обрабатывались.
Теперь вы отмечаете повреждение данных, поэтому я предполагаю, что вы имеете в виду возможность записи журнала аудита, но фактическое событие не обрабатывается. Это немного сложнее. Это две различные операции, которые вы пытаетесь выйти замуж. Простой ответ - действительно, вы не можете гарантировать, что это не выйдет из строя. Между обеими операциями нет транзакции (и вы не хотите, чтобы она была в распределенной системе). Подумайте об аудите как о намерении выполнить операцию, а не о том, что операция была фактически завершена. Вы не можете предположить, что обработка завершится успешно просто потому, что сообщение было предоставлено системе. Как только происходит обработка, он может зарегистрировать, что операция была фактически завершена. Или, возможно, он выдает сообщение другому аудитору для записи. Это даст вам лучшую метрику для анализа в вашей системе: количество запрошенных операций и количество фактически завершенных операций.При просмотре в течение определенного периода времени этот показатель может предоставить вам фактическую успешную пропускную способность вашей системы.
Если я вас хорошо понимаю, вы можете иметь время простоя для подписчика, сообщение останется в подписке. Когда абонент перезапустится, он найдет обратно сообщения, отправленные в тему во время простоя. Таким образом, вам не нужны три подписчика для обеспечения безопасности –