Дублирование сообщений: клиент может отказать после получения сообщения, его обработки, но перед подтверждением сообщения. Тогда брокер доставит сообщения повторно, и мы получим дубль. В идеале брокер должен сохранять порядок следования сообщений (отправлять сообщение тому же потребителю), тогда потребитель может проигнорировать сообщение, которое уже обработано и отправить подтверждение обработки. Существупет несколько методов борьбы с повторяющимися сообщениями:
* Добавление идемпотентных дескрипторов: логика обработки считается идемпотентной, если её многократное выполнение с одинаковыми входными параметрами не несёт рассогласования данных. Например, отмена уже отменённого заказа - идемпотентная операция. К сожалению, логику обработки не всегда можно сделать идемпотентной, и брокер не всегда может отправить сообщение тому же получателю (например, при выходе последнего из строя). В таких случаях обработчики должны отслеживать сообщения и отклонять результаты.
* Отслеживание и отклонение дубликатов: например, обработчик сообщений авторизует банковскую карту. Для каждого заказа он должен выполнить ровно одну авторизацию. Идемпотенция обработчика в этом случае достигается отслеживанием и отклонением дублей. В качестве простого решения можно сделать так, чтобы потребитель отслеживал обработанные сообщения с помощью идентификаторов (например, записанных в БД), и отклонял те, что уже были обработаны. Ещё один вариант состоит в том, чтобы обработчик записывал сообщения не в отдельную таблицу, а в таблицу приложения. Этот подход полезен при использовании NoSQL, которые имеют ограниченную транзакционную модель и не поддерживают обновление двух таблиц в рамках одной транзакции (Про NoSQL я писал выше, и писал много - смотри конспекты "Высоконагруженных приложений" от Клеппмана).