Как избежать отправки повторных сообщений - PullRequest
Новая
       25

Как избежать отправки повторных сообщений

0 голосов
/ 19 декабря 2018

Из-за политики компании мы (моя небольшая команда) не могли использовать менеджер очередей в прошлом (единственным разрешенным был Websphere MQ, но для этого не было бюджета).Мы реализовали очереди, используя базу данных.Наши приложения ориентированы на базы данных в .NET.Недавно это было изменено - мы можем использовать ActiveMQ или Rabbit.Мы начали думать о переносе наших очередей, но еще не решили, какие из них будут использоваться.

Оказалось, что это не так просто, как кажется на первый взгляд.У нас есть несколько сценариев, когда мы проверяем, находится ли сообщение в очереди, используя бизнес-ключ, чтобы избежать повторения.Например: когда нетерпеливый пользователь отправляет заявку на кредитную карту дважды (дважды щелкнула кнопка «Отправить»), потому что он еще не видит изменения статуса.Мы несем ответственность за бэкэнд и не имеем контроля над клиентским приложением.

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

Можно ли проверить, находится ли сообщение в очереди, используя некоторые бизнес-данные?

1 Ответ

0 голосов
/ 05 января 2019

Мой колледж нашел решение.В настоящее время у нас есть очередь, реализованная в одной таблице базы данных со следующими данными: msg_type, msg_key (это бизнес-ключ, который нам нужен, чтобы быть уникальным), msg_body, status, request_time, processing_time, retry_count и error_code.

Идеяследующее: эта таблица будет по-прежнему использоваться только для целей дедупликации, а администратор очередей - только для очередей (без функции дедупликации).

Поэтому мы удалим ненужные данные из таблицы.Остальные поля: msg_type и msg_key.

Алгоритм:

  1. Наш сервис получает запрос

  2. Проверьте, повторяется ли сообщение сбизнес ключ в таблице.Если это так, то возникает исключение.

  3. Поместить сообщение в очередь и новый ключ сообщения в таблицу

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

...