Soul Crit интервьюера: как обеспечить 100% успешную доставку сообщений? Как гарантировать идемпотентность сообщения?

Java
Soul Crit интервьюера: как обеспечить 100% успешную доставку сообщений? Как гарантировать идемпотентность сообщения?

Возможна ли потеря сообщения?

  1. В процессе отправки Сообщения Брокеру Продюсер теряется из-за проблем с сетью, или Сообщение приходит к Брокеру, но есть проблема и оно не сохраняется.

В ответ на эту проблему Producer может открыть транзакцию MQ.Если процесс ненормальный, то он будет откатан, но есть большая проблема.Если вы отправите транзакцию, она будет там заблокирована, что сильно повлияет на производительность.Производственная среда определенно не откроет транзакцию. , как правило, используйте механизм подтверждения

  1. Брокер получает Сообщение и временно сохраняет его в памяти, Потребитель не успел его воспринять, и Брокер вешает трубку.

Это можно решить с помощью настроек сохранения:

(1)При создании очереди установите постоянство, чтобы брокер сохранял метаданные очереди, но не сохранял сообщения в очереди;(2)Если установить для параметра deliveryMode сообщения значение 2, сообщение может сохраняться на диске, так что подтверждение Producer уведомления будет отправлено только после того, как сообщение будет сохранено на диске.

После этих двух шагов, даже если Брокер зависнет, Продюсер точно не получит акк, поэтому может отправить повторно.

  1. Потребитель потребляет Сообщение, но есть внутренняя проблема, и Сообщение не было обработано.Брокер считает, что Потребитель закончил обработку и будет отправлять только последующие сообщения.

В это время необходимо отключить автоподтверждение, а после обработки сообщения выполнить ручное подтверждение

Как обеспечить надежность доставки?

  1. Гарантирует успешную доставку сообщения

  2. Обеспечьте успешный прием узлов MQ

  3. Отправитель получает подтверждающий ответ от узла MQ (брокера).

  4. Идеальный механизм компенсации сообщений

решение

репозиторий новостей

  1. репозиторий новостей, Измените статус сообщения, и нагрузка на базу данных велика для сред с большим количеством одновременных операций, поскольку необходимо записать несколько баз данных.

Общий процесс:

  1. Бизнес-данные и сообщения хранятся в библиотеке

  2. Производитель отправляет сообщение Брокеру

  3. Брокер возвращает ответ Confirm на производственную сторону.

  4. Получить подтверждение, изменить статус сообщения

  5. Распределенная задача синхронизации для получения статуса сообщения

  6. Если сообщение не может быть успешно доставлено, отправьте его повторно и запишите количество повторных отправок.

  7. После 3 повторных передач состояние изменяется, и можно выполнить только ручное вмешательство.

Задержка доставки сообщений

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

Общий процесс:

  1. Восходящая служба сначала сохраняет бизнес-код и отправляет сообщение брокеру.

  2. Отправить второе сообщение с отложенным подтверждением

  3. Нижестоящие сервисы прослушивают сообщения для потребления

  4. Отправьте сообщение подтверждения, здесь не механизм подтверждения, а новое сообщение

  5. Отслеживайте сообщение подтверждения через службу обратного вызова, а затем сохраняйте сообщение

  6. Когда служба обратного вызова обнаружит сообщение с отложенным подтверждением, она запросит это сообщение в базе данных.

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

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

RabbitMQ может привести к неидемпотентным ситуациям

  1. Надежный механизм доставки сообщений: когда потребитель отвечает на подтверждение, происходит сбой сети, а производитель не получает подтверждения. Запланированный опрос задачи может повторно отправить сообщение, поэтому потребитель получит два сообщения.

  2. Сетевой джиттер возникает в процессе передачи сообщений между MQ Broker и потребителем.

  3. Сбой или исключение потребителя

Кафка может показаться неидемпотентным

Когда Потребительское смещение конца не отправлено, Потребитель перезапускается, и на этот раз будут случаи повторного потребления.

решение

Уникальный идентификатор + код отпечатка пальца

Общая реализация относительно проста: требуется запись в базу данных, использование первичного ключа базы данных для дедупликации и использование идентификатора для выполнения алгоритма маршрутизации подбазы данных и подтаблицы из идемпотентности одной базы данных. к идемпотентности нескольких баз данных.

  1. здесьуникальный идентификаторКак правило, это первичный ключ бизнес-таблицы, например идентификатор продукта.
  2. код отпечатка пальца: для каждой операции генерируется код отпечатка пальца, который может состоять из метки времени + бизнес-номера + ..., цель состоит в том, чтобы гарантировать, что каждая операция проходит нормально.

Общий процесс:

  1. Требуется унифицированная служба генерации идентификаторов.Для обеспечения надежности вышестоящая служба также имеет локальную службу генерации идентификаторов, а затем отправляет сообщение брокеру.
  2. Компонент маршрутизации правила ID необходим для мониторинга сообщения, сначала поместить его в хранилище, если запись прошла успешно, доказывает отсутствие дублирования, а затем отправить его в нижестоящий поток, если будет обнаружено, что это сообщение есть в библиотеке он не будет отправлен в нисходящий поток

Рекомендуемое чтение

  1. Определенная степень и две стороны: данные MySQL на уровне миллионов, как выполнить запрос на подкачку? говорить об идеях
  2. Сравнение очередей сообщений Redis, Kafka и Pulsar
  3. После столь долгого использования IDEA вы даже не знаете, что есть функция, называемая автодополнением!
  4. Почему инструмент преобразования свойств BeanUtils устарел
Категории