Разделите три события
Отправитель передал сообщение брокеру, брокер доставил его обработчику, обработчик выполнил работу. Это разные события. Подтверждение приёма со стороны брокера не означает, что потребитель уже закончил задание. Подтверждение потребителя, в свою очередь, относится к обработке доставки. В нашей модели сообщение просит отметить учебную заявку сорок два как готовую. Для наблюдения понадобятся три отдельные записи: сообщение принято, сообщение получено, состояние заявки сохранено. Объединение их в одно расплывчатое слово готово скрывает место возможного сбоя.
Найдите промежуток неопределённости
Представим, что обработчик получил задание и сохранил для заявки статус готова. Затем соединение оборвалось, а подтверждение обработки до брокера не дошло. У брокера нет достаточного основания считать доставку завершённой. В очереди с рассматриваемым режимом неподтверждённое сообщение после обнаружения разрыва может снова попасть к потребителю. Получатель увидит задание ещё раз, хотя полезное изменение уже произошло. Внешне это похоже на дублирование работы, но причина заключается в разнице между совершённым действием и известным другой стороне результатом.
Повтор доставки не обязан повторять эффект
Для нашей заявки повторно установить тот же статус готова означает оставить состояние прежним. Если же каждое сообщение без проверки создаёт новую заявку, повтор даст лишнюю запись. Способность повторного выполнения сохранять тот же предусмотренный результат называют идемпотентностью. Она относится к конкретной операции и её условиям, а не возникает от самого присутствия брокера. В учебном примере важно узнавать одну и ту же заявку по устойчивому идентификатору. Два разных задания нельзя объединять только потому, что их тексты похожи или поступили почти одновременно.
Бумажная схема ещё не гарантирует надёжность
Список обработанных сообщений кажется простым решением, но между полезным действием и сохранением отметки тоже возможен сбой. Поэтому в реальной системе отдельно продумывают согласованность изменений, повторные попытки и наблюдение за ошибками. Здесь мы не проектируем такую систему целиком. Наша узкая проверка состоит в другом: понять, какое событие произошло, о каком событии известно брокеру и какой эффект даст повтор. Настройки подтверждения и восстановления нужно проверять для выбранного продукта и протокола, поскольку одинаковые слова не делают все очереди одинаковыми.
Попробуйте на практике
Разыграйте на бумаге две доставки одного задания, не подключая сервер и не отправляя реальные сообщения.
- Нарисуйте три столбца: очередь, обработчик, заявка сорок два. Впишите одно задание изменить состояние этой заявки на готова.
- Отметьте получение сообщения и изменение состояния. Между изменением и подтверждением поставьте знак разрыва соединения.
- Изобразите повторную доставку того же задания. Сравните два правила: снова установить статус существующей заявки или каждый раз создавать новую запись.
- Посчитайте итоговые заявки в обоих вариантах и укажите, какое подтверждение отсутствовало. Отдельно запишите, что бумажная модель не проверяет реальные сбои хранения.
Как проверить результат. При повторной установке статуса остаётся одна исходная заявка. Если на каждую из двух доставок создавать новую запись, к исходной добавятся ещё две. Вы различаете факт выполненной работы и отсутствие подтверждения у брокера.
Частые вопросы
Можно ли подтвердить сообщение сразу, чтобы повторов не было?
Раннее подтверждение меняет риск: при последующем сбое работа может остаться невыполненной, хотя очередь считает доставку завершённой. Выбор момента требует понимания задачи.
Повторное сообщение всегда означает повторное выполнение?
Нет. Обработчик мог не получить первую доставку либо мог остановиться раньше полезного действия. Нужно проверять состояние операции, а не делать вывод только по факту повтора.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.