Ответ
Гарантия доставки (delivery guarantee) в асинхронных системах, построенных вокруг брокеров сообщений (Message Brokers), обеспечивается комбинацией нескольких ключевых механизмов. Без них сообщения могли бы теряться при сбоях.
Основные механизмы:
-
Сохранение (Persistence) сообщений и метаданных.
- Сообщение, принятое брокером (например, RabbitMQ, Apache Kafka), записывается на диск или реплицируется в кластер до того, как брокер подтвердит его получение отправителю (Publisher Acknowledgement). Это защищает от потери данных при падении брокера.
- Очереди (queues) и топики (topics) также объявляются как устойчивые (durable).
-
Подтверждение потребителя (Consumer Acknowledgement).
- После успешной обработки сообщения потребитель (Consumer) должен явно отправить брокеру подтверждение (ACK). Только получив его, брокер удаляет сообщение из очереди.
- Если подтверждение не пришло (таймаут) или потребитель явно отказался (NACK), брокер либо возвращает сообщение в очередь для повторной обработки, либо перемещает его в "мертвую букву" (Dead Letter Queue).
-
Повторные попытки (Retries) и отказоустойчивость.
- Потребитель или сама инфраструктура могут реализовывать политики повторных попыток при временных сбоях (например, недоступность БД).
-
Идемпотентность обработчика.
- Гарантия "хотя бы раз" (at-least-once delivery), которую дают многие системы, означает, что одно и то же сообщение может быть доставлено потребителю несколько раз. Поэтому логика обработки должна быть идемпотентной: повторная обработка того же сообщения не должна вызывать побочных эффектов (например, двойное списание средств). Этого можно достичь через проверку уникальных ID сообщений или использование механизмов оптимистичной блокировки.
Практический пример с RabbitMQ и PHP (библиотека php-amqplib):
// 1. Отправитель (Publisher) с подтверждением и сохранением на диск
$channel->confirm_select(); // Включаем режим подтверждений от брокера
$channel->queue_declare('task_queue', false, true, false, false); // Durable queue
$msg = new AMQPMessage(
$body,
['delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT] // Persistent message
);
$channel->basic_publish($msg, '', 'task_queue');
$channel->wait_for_pending_acks(); // Ждем подтверждения от брокера
// 2. Потребитель (Consumer) с ручным подтверждением
$channel->basic_consume(
'task_queue',
'',
false,
false, // <-- Важно: auto_ack = false (отключаем авто-подтверждение)
false,
false,
function (AMQPMessage $msg) {
try {
echo " [x] Received ", $msg->body, "n";
// Имитация работы...
processMessage($msg->body);
// 3. Явное подтверждение успешной обработки
$msg->ack();
echo " [x] Donen";
} catch (Exception $e) {
echo " [x] Failed: ", $e->getMessage(), "n";
// 4. Отказ с требованием повторной доставки
$msg->nack(true); // Параметр `requeue = true`
}
}
);Таким образом, гарантия доставки — это не один механизм, а целая стратегия, реализуемая на уровне брокера, отправителя и потребителя.
Ответ 18+ 🔞
А, ну слушай, про гарантию доставки в этих асинхронных системах с брокерами. Это ж, бля, целая наука, а не просто "отправил и забыл". Без правильных механизмов твои сообщения могут хуй с горы свалиться при первом же чихе сервера, и потом сиди и думай, куда деньги делись.
Короче, на чём всё держится:
-
Сохранение всего на диск, ёпта.
- Брокер (типа RabbitMQ или Kafka) должен сначала плюхнуть сообщение и все его метаданные на жёсткий диск или размножить по кластеру, и только потом сказать отправителю: "Окей, принял, свободен". Это называется Publisher Acknowledgement. Если брокер накроется медным тазом до того, как запишет, то сообщение — тю-тю. А так — поднялся и прочитал с диска. Очереди тоже надо объявлять устойчивыми (durable), а то получится манда с ушами: сообщение сохранил, а очередь испарилась.
-
Подтверждение от потребителя, мать его.
- Потребитель, получив и обработав сообщение, обязан явно послать брокеру сигнал "Ага, всё, я это схавал". Это ручное подтверждение (ACK). Пока этого сигнала нет, брокер считает, что сообщение ещё в работе, и не удаляет его. Если потребитель сдох, завис или просто отправил отказ (NACK), брокер либо суёт сообщение обратно в очередь, либо пихает его в специальную помойку — Dead Letter Queue, чтобы потом разобраться. Автоподтверждение (auto_ack) — это пиздец, а не гарантия, только для тестов.
-
Повторные попытки и недроченная отказоустойчивость.
- Ну, тут всё ясно: если что-то временно легло (база, сеть, апокалипсис), надо пробовать ещё. Но аккуратно, а то заспамишь самого себя.
-
Идемпотентность — слово страшное, но смысл простой.
- Поскольку многие системы работают по принципу "хотя бы раз доставлю" (at-least-once), одно и то же сообщение может прилететь к тебе несколько раз. Представь: обработал ты платёж, отправил ack, а он не дошёл. Брокер пришлёт сообщение снова. И если твоя логика не идемпотентна, то списание произойдёт дважды. Волнение ебать! Поэтому нужно уметь отсекать дубли: проверять уникальные ID сообщений, использовать блокировки — в общем, чтобы повторный приход одного и того же не вызывал новых эффектов. Иначе будет тебе хиросима, а не система.
Пример на PHP с RabbitMQ (библиотека php-amqplib):
Смотри, как это выглядит в коде. Главное — не накосячить с настройками.
// 1. Отправитель. Включаем подтверждения от брокера и настойчивость.
$channel->confirm_select(); // Говорим брокеру: "чувак, давай по-взрослому, жди подтверждения записи"
$channel->queue_declare('task_queue', false, true, false, false); // Объявляем DURABLE очередь
$msg = new AMQPMessage(
$body,
['delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT] // И само сообщение делаем PERSISTENT
);
$channel->basic_publish($msg, '', 'task_queue');
$channel->wait_for_pending_acks(); // Терпеливо ждём, пока брокер не скажет "записал, расслабься"
// 2. Потребитель. Ручное подтверждение — наше всё.
$channel->basic_consume(
'task_queue',
'',
false,
false, // <-- Вот это КРИТИЧНО! auto_ack = FALSE. Выключаем эту ебальную автомагию.
false,
false,
function (AMQPMessage $msg) {
try {
echo " [x] Received ", $msg->body, "n";
// Делаем какую-то полезную, но опасную работу...
processMessage($msg->body);
// 3. Всё прошло огонь, воду и медные трубы? Шлём явный ack.
$msg->ack();
echo " [x] Donen";
} catch (Exception $e) {
echo " [x] Failed: ", $e->getMessage(), "n";
// 4. Всё пошло по пизде? Отказываемся и просим доставить снова.
$msg->nack(true); // Параметр `requeue = true` — "отправь, сука, обратно в очередь"
}
}
);Так что, короче, гарантия доставки — это не какая-то одна волшебная галочка в настройках. Это, бля, целая стратегия, которую нужно выстраивать на всех трёх фронтах: и брокер должен быть настроен правильно, и отправитель должен ждать подтверждения записи, и потребитель должен аккуратно работать с подтверждениями обработки. И да, делать свою логику идемпотентной, иначе доверия ебать ноль ко всей этой конструкции.
