Асинхронность и сообщения: обзор с выбором ответа
Синтез всего асинхронного раздела в формате с выбором ответа: семантика доставки и effectively-once, очередь против лога и реплей, хореография против оркестрации, outbox против двойной записи и ловушка бэклога безграничной очереди.
Шесть вопросов через весь раздел. Каждый — решение, которое ты принимаешь, ставя очередь в дизайн, выбирая стиль координации или ревьюя асинхронный конвейер: не определение для пересказа, а выбор за семантикой доставки, outbox и ловушкой бэклога.
Подтверди, что умеешь выбрать семантику доставки и сделать её effectively-once, выбрать очередь против лога из требования реплея, разместить процесс на оси хореография/оркестрация, распознать и починить двойную запись через outbox и отвергнуть безграничную очередь по её поведению с бэклогом.
Вендор рекламирует «exactly-once доставку» для своей очереди. Как это точно читать и что твой consumer всё равно обязан делать?
Надо подключить новый consumer, что переобработает события за последние 14 дней, чтобы построить свежую проекцию. Какая подложка сообщений поддерживает это напрямую?
7-шаговому процессу заказа нужны компенсирующие действия при сбое (возврат, освобождение товара), и дежурный должен отвечать «где сейчас заказ #X?». Какой стиль координации подходит?
Обработчик делает `db.commit(order)`, затем `broker.publish(event)`; изредка заказ сохранён, но событие так и не срабатывает. В чём баг и стандартная починка?
Конвейер использует безграничную очередь, «чтобы никогда не терять события». Downstream застывает на 30 минут в пик. Каков вероятный исход и корневая починка?
На топике Kafka с 6 партициями нужно обрабатывать события каждого аккаунта по порядку, распараллеливая между аккаунтами. Как ключевать и потреблять?
- 01Почему «exactly-once доставка» на деле effectively-once и чего это от тебя требует?
- 02Как outbox побеждает проблему двойной записи и какую гарантию даёт?
Сквозная линия этого раздела в том, что асинхронность покупает развязку и платит семантикой, под которую надо проектировать. Очередь превращает синхронную зависимость по доступности в асинхронную по задержке, но доставка честно at-least-once (или с потерями at-most-once), поэтому exactly-once — это effectively-once — идемпотентные consumer’ы с дедуп-ключом. Pub/sub рассылает веером по подписчикам, и глубокий раскол — брокер против лога: лог удерживает сообщения и отслеживает пер-consumer офсеты, делая реплей и бэкфилл first-class, а брокер с удалением-при-потреблении не может. Координация многошаговых процессов — хореография (развязано, простые потоки) против оркестрации (сага, держащая состояние процесса и компенсации — для сложных потоков). Транзакционный outbox побеждает проблему двойной записи, делая изменение состояния и событие одной локальной транзакцией с асинхронным relay, гарантируя «никогда не потеряно, возможно дублировано». А каждой очереди нужна граница: безграничная очередь — латентная катастрофа, отмывающая краткий затык в долгий бэклог, поэтому ты ограничиваешь, сбрасываешь нагрузку, лимитируешь темп по арендатору и алармишь на лаг. На этой глубине senior-ход — назвать компромисс до добавления компонента.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.