Перейти на PRO

Расскажи про доставку сообщений в распределенных системах

Тип вопроса: Распределенные системы Вероятность: 33% Категория: Data Инженер

Ответ

При проектировании микросервисных и event-driven архитектур я сталкивался с необходимостью выбора модели доставки сообщений. Это фундаментальный выбор, влияющий на отказоустойчивость и консистентность всей системы.

Основные модели гарантий доставки:

  1. At-most-once (максимум один раз): Сообщение может быть потеряно. Это модель по умолчанию для многих систем, когда скорость важнее надежности. Использовал, например, для отправки метрик или логов, где потеря отдельных данных некритична.
  2. At-least-once (минимум один раз): Гарантируется, что сообщение будет доставлено, но возможны дубликаты из-за повторных отправок при сбоях. Это самая распространенная модель в моих проектах. Для обработки дублей на стороне потребителя необходимо реализовывать идемпотентность.
  3. Exactly-once (ровно один раз): Сложная модель, требующая координации между продюсером, брокером и консьюмером. На практике она часто реализуется как идемпотентный продюсер + транзакции + идемпотентный консьюмер.

Пример из практики с Apache Kafka: Мы строили финансовый пайплайн, где дублирование транзакций было недопустимо. Использовали комбинацию настроек в Kafka для достижения семантики exactly-once в рамках одного приложения.

// Конфигурация продюсера на Java
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "kafka-broker:9092");
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true"); // Включаем идемпотентность
props.put(ProducerConfig.ACKS_CONFIG, "all"); // Ждем подтверждения от всех реплик
props.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "my-transactional-id"); // Для транзакций

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

producer.initTransactions(); // Инициализация транзакций

try {
    producer.beginTransaction();
    // Отправка нескольких сообщений в рамках одной транзакции
    producer.send(new ProducerRecord<>("orders", "order-123", "{...}"));
    producer.send(new ProducerRecord<>("audit-log", "audit-123", "{...}"));
    producer.commitTransaction(); // Атомарный коммит всех отправленных сообщений
} catch (Exception e) {
    producer.abortTransaction(); // Откат всей пачки в случае ошибки
    throw e;
}

С какими проблемами сталкивался:

  • Сетевые задержки и таймауты: Приводили к ложным ретраям и дублям. Решение — тщательная настройка таймаутов и использование экспоненциального отката (exponential backoff).
  • Нарушение порядка доставки при ретраях: В Kafka порядок гарантируется в пределах одного партишна. При использовании max.in.flight.requests.per.connection=1 (для at-least-once) порядок сохраняется, но падает производительность.
  • Распределенный консенсус: Для управления метаданными (например, офсетами консьюмеров или состоянием транзакций) брокеры используют Apache ZooKeeper (или KRaft в новых версиях Kafka), который реализует алгоритмы консенсуса, такие как ZAB.

Ответ 18+ 🔞

Давай разберем эту тему, но без занудства, а как есть на самом деле. Сидишь ты такой, проектируешь свою микросервисную хуету, и тут бац — надо решить, как сообщения между сервисами летать будут. А выбор-то, блядь, фундаментальный! От него потом вся твоя архитектура либо летает, либо накрывается медным тазом при первой же проблеме.

Вот три главные модели, с которыми придется жить. Выбирай, но выбирай с умом, а не как мартышлюшка.

1. At-most-once (максимум один раз). Это по сути «отправил и забыл, как в помойку». Сообщение может спокойно потеряться где-то в сетевых дебрях. Используется, когда да похуй на потерю пары записей. Ну, например, для логов или метрик. Упала одна метрика — мир не рухнет, ёпта. Главное, скорость.

2. At-least-once (минимум один раз). А вот это уже наша, народная, самая частая модель. Гарантия есть: сообщение точно дойдет. Но есть нюанс, блядь! Из-за ретраев и сбоев оно может прийти несколько раз. Дубликаты, Карл! Поэтому на стороне того, кто сообщение жрёт, нужно обязательно делать идемпотентность. Чтобы обработал он одно и то же сообщение пять раз, а результат был как от одного. Иначе будет тебе хиросима и нигерсраки в данных.

3. Exactly-once (ровно один раз). Священный Грааль, ёперный театр! Все хотят, но мало кто умеет правильно готовить. На практике это обычно комбинация: идемпотентный отправитель + транзакции + идемпотентный получатель. Сложно, ресурсоёмко, но иногда надо.

Вот реальный пример из жизни, когда пришлось выкручиваться. Делали мы финансовый пайплайн на Kafka. Там дублирование платежа — это пидарас шерстяной, клиенты бы нам такого не простили. Пришлось настраивать эту самую семантику exactly-once в рамках одного приложения. Выглядело это примерно так:

// Конфигурация продюсера на Java
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "kafka-broker:9092");
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true"); // Включаем идемпотентность, чтобы продюсер сам не слал дубли
props.put(ProducerConfig.ACKS_CONFIG, "all"); // Ждём подтверждения от ВСЕХ реплик, а не просто "отправил и похуй"
props.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "my-transactional-id"); // Вот это ключевое для транзакций

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

producer.initTransactions(); // Говорим Кафке: "Внимание, ща будут дела!"

try {
    producer.beginTransaction();
    // Кидаем несколько сообщений в разные топики как одну операцию
    producer.send(new ProducerRecord<>("orders", "order-123", "{...}"));
    producer.send(new ProducerRecord<>("audit-log", "audit-123", "{...}"));
    producer.commitTransaction(); // Всё ок? Фиксируем разом! Атомарно, блядь!
} catch (Exception e) {
    producer.abortTransaction(); // Чёт пошло не так? Откатываем ВСЁ, что в этой транзакции было.
    throw e;
}

А теперь про проблемы, с которыми точно столкнёшься, и волнение ебать:

  • Сетевые лаги и таймауты. Это классика. Из-за них система думает, что сообщение не дошло, и шлет его снова. А оно, сука, уже летит, просто медленно. Получаются дубли. Лечится тонкой настройкой таймаутов и алгоритмом экспоненциальной отсрочки (exponential backoff), чтобы не дудосить брокер.
  • Нарушение порядка при ретраях. В Kafka порядок гарантируется только в рамках одного партишна. Если разрешить несколько параллельных отправок (max.in.flight.requests.per.connection больше 1), то при ретрае порядок может поехать. Ставишь 1 — порядок есть, но производительность падает. Выбирай, что для тебя важнее.
  • Вся эта магия консенсуса. Чтобы управлять офсетами или состоянием транзакций, брокерам нужно между собой договориться. Для этого они используют Apache ZooKeeper (или новый KRaft). А там под капотом свои алгоритмы, вроде ZAB. Это, конечно, надёжно, но добавляет сложности — доверия ебать ноль к простым конфигурациям. Один косяк в кворуме — и вся система может встать.
© ХакСобесов, 2026
support@hacksobesov.com