Гарантированное однократное сообщение sh сообщения

Question

Дано:

1. Я как не очень опытный пользователь очередей
2. SQL Таблица сервера MessagesToPu sh
3. RabbitMq обмен в одну очередь (или несколько - Я думаю, что это не важно здесь)
4. c# программа, которая должна прочитать из MessagesToPu sh и отправить это сообщение для обмена ровно один раз (если вы знаете какой-то способ принудительного применения на стороне кролика - скажите мне, я может что-то упустить)
5. Алгоритм:
   • принять запись о состоянии «не отправлено» (для простоты нас не волнует параллелизм, массовая обработка и т. д. c здесь и позже)
   • отправить / зафиксировать на обмен кроликами
   • обновить состояние строки в БД (установить состояние = 'отправлено')
   • повторить

А вот какой-то ментальный блок, который я не могу преодолеть - очевидно, у нас есть проблема, если мы, например, зависаем между коммитом для обмена и фиксацией БД. В этом случае мы можем отправить наше сообщение дважды. Да, мы можем реализовать проверку на двойники на стороне потребителя - но это довольно дорого во многих отношениях. Итак, вот мой вопрос: есть ли хороший способ обеспечить subj ?

Answer 1

Несколько мыслей по этому поводу:

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

Ровно после доставки математически невозможно .

Почему? Рассмотрим случай отправки текста ненадежному другу (у всех нас есть). Этот конкретный друг отключил уведомления о прочтении своего сообщения. Вы отправляете ему сообщение, чтобы узнать, готов ли он к обеду. Вы ждете несколько минут ответа. Он не отвечает. Что случилось?

• Получил ли он ваше сообщение и проигнорировал его (как он склонен делать)? Если так, возможно, он не хочет, чтобы его беспокоили. Отправка другого сообщения может раздражать его. Вы все равно отправляете свое сообщение?
• Возможно, он не получил ваше сообщение, хотя iPhone указывает, что оно было успешно отправлено. Вы запланировали на ужин, и если он не получил его, теперь это будет выглядеть как , что вы грубите.

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

Далее , рассмотрите случай, когда ваше текстовое сообщение вообще не отправляется , Ваш телефон показывает маленький (!) Значок рядом с сообщением. Вы нажимаете на нее, а затем нажимаете кнопку «отправить еще раз». Это пример хотя бы один раз семантики доставки. Сообщение может или не может быть фактически прошло в первый раз, но ваш телефон показывает ошибку, и вы отправляете снова. Неизвестно вам, две копии сообщения теперь были отправлены.

И что?

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

Итог : если важна гарантированная доставка, проектируйте вашу систему как минимум на семантика однократной доставки .