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

Question

Работа с ядовитыми сообщениями (выдает исключение при потреблении) из Azure Сервисная шина может привести к циклам до тех пор, пока число повторных попыток не достигнет maxDeliveryCount настройки подписки topi c.

1. Увеличивается ли SequenceNumber сообщения, добавляемого Azure Сервисная шина, при каждой неудачной попытке, пока она не достигнет maxDeliveryCount?
2. Настройка maxDeliveryCount = 1, Это лучший метод для работы с ядовитыми сообщениями, чтобы потребитель никогда не пытался дважды обработать сообщение, если оно не удалось

Answer 1

Рекомендации зависят от вашего приложения и вашего подхода к повторным попыткам.

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

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();
        }
    }

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

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

Если вы читаете сообщения в пакете, полная партия будет повторно обработана, если произошла ошибка any of message.

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