лучшие практики обработки подозрительных сообщений для темы служебной шины Azure

Лучшие практики зависят от вашего приложения и вашего подхода к повторной попытке.

Большую часть времени я замечал, что сообщение не получилось

1. Зависимая служба недоступна (Redis, проблема с подключением SQL)

2. Сообщение о неисправности (сообщение не имеет обязательного параметра или некорректное значение)

3. Проблема с кодом процесса (ошибка в коде обработки сообщений)

Для 1-го и 3-го сценариев я создал веб-задание C # для запуска и повторной обработки мертвого письма.

Ниже мой код

internal class Program
    {
        private static string connectionString = ConfigurationSettings.AppSettings["GroupAssetConnection"];
        private static string topicName = ConfigurationSettings.AppSettings["GroupAssetTopic"];
        private static string subscriptionName = ConfigurationSettings.AppSettings["GroupAssetSubscription"];
        private static string databaseEndPoint = ConfigurationSettings.AppSettings["DatabaseEndPoint"];
        private static string databaseKey = ConfigurationSettings.AppSettings["DatabaseKey"];
        private static string deadLetterQueuePath = "/$DeadLetterQueue";

        private static void Main(string[] args)
        {

            try
            {
                ReadDLQMessages(groupAssetSyncService, log);
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
                throw;
            }
            finally
            {
                documentClient.Dispose();
            }
            Console.WriteLine("All message read successfully from Deadletter queue");
            Console.ReadLine();
        }

        public static void ReadDLQMessages(IGroupAssetSyncService groupSyncService, ILog log)
        {
            int counter = 1;
            SubscriptionClient subscriptionClient = SubscriptionClient.CreateFromConnectionString(connectionString, topicName, subscriptionName + deadLetterQueuePath);
            while (true)
            {
                BrokeredMessage bmessgage = subscriptionClient.Receive(TimeSpan.FromMilliseconds(500));
                if (bmessgage != null)
                {
                    string message = new StreamReader(bmessgage.GetBody<Stream>(), Encoding.UTF8).ReadToEnd();
                    syncService.UpdateDataAsync(message).GetAwaiter().GetResult();
                    Console.WriteLine($"{counter} message Received");
                    counter++;
                    bmessgage.Complete();
                }
                else
                {
                    break;
                }
            }

            subscriptionClient.Close();
        }
    }

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

Я не буду рекомендовать maxDeliveryCount=1. Если возникают какие-либо проблемы с сетью / подключением, встроенная повторная попытка обработает и удалит из очереди. Когда я работал в финансовом приложении, я держал maxDeliveryCount=5, в то время как в моем приложении IoT это maxDeliveryCount=3.

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

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