Очереди, потоки, события
Гарантии доставки: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — доказательство невозможности, три плеча сбоев, idempotent-консьюмеры, Kafka EOS, SQS-таймауты и outbox.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном инциденте — не определение для заучивания, а компромисс, который надо взвесить, пока клиентов списывают дважды.
Цель
Убедись, что связываешь доказательство невозможности, плечи сбоев, идемпотентность консьюмера, транзакции Kafka, механику SQS и outbox в одну связную историю end-to-end корректности.
Викторина
Completed
Вендор рекламирует у очереди 'exactly-once delivery'. Senior-ревьюер возражает. Какое возражение точное и корректное?
Heads-up Больше реплик улучшают durability, а не двустороннее согласие. Никакая репликация не даёт producer и consumer общей уверенности над теряющим каналом; невозможность информационно-теоретическая, а не аппаратное ограничение.
Heads-up TCP дедуплицирует пакеты внутри соединения; он ничего не говорит о повторной доставке на уровне приложения после краша консьюмера или реконнекта. Дубликаты гарантий доставки живут выше транспортного уровня.
Heads-up Two-phase commit между producer, брокером и consumer непрактичен на пропускной способности очереди и всё равно не побеждает асимметрию Two Generals. Production-ответ — односторонний дедуп консьюмера, а не распределённое согласие.
Викторина
Completed
Из трёх плеч сбоев какое порождает дубликаты, с которыми реально борешься в проде, и почему фикс ложится на консьюмера?
Heads-up Ретраи плеча 1 при потере ack действительно дают дубликаты, но idempotent producer Kafka нейтрализует их ценой ~3%. Постоянная боль прода — плечо 3, где обработка уже дала видимый side effect до краша.
Heads-up Плечо 2 — риск потери при неправильной конфигурации (acks не all), а не источник дубликатов. Корректно настроенная durability дубликатов не порождает.
Heads-up Большой таймаут уменьшает окна одновременных дубликатов, но никогда не убирает краш после обработки до ack. At-least-once означает, что дубликаты — структурная неизбежность, которую проектируют, а не вытюнивают.
Викторина
Completed
Команда реализует дедуп консьюмера так: SELECT по msg_id; если нет — вызвать Stripe и сделать INSERT. При ребалансе consumer-group всё равно видят двойные списания. В чём структурный дефект?
Heads-up Больший таймаут сужает окно, но гонка SELECT/INSERT — баг корректности независимо от тайминга; ребаланс или любая одновременная доставка её снова открывает. Дедуп надо сделать атомарным, а не просто медленнее в гонке.
Heads-up TTL здесь ни при чём; очереди передоставляют за секунды. Двойное списание — от неатомарного локального дедупа, который пропускает два вызова side effect раньше, чем приземлится любой INSERT.
Heads-up Индекс ускоряет поиск, но не сериализует две одновременные транзакции; только попадание в UNIQUE-ограничение внутри той же транзакции, что и side effect, предотвращает дубликат.
Викторина
Completed
У Kafka Streams-джобы стоит enable.idempotence=true и transactional.id, она пишет в output-топик И в таблицу Postgres. После рестарта брокера в Postgres всё равно дубли строк. Почему?
Heads-up Неуникальный transactional.id вызывает проблемы fencing, но даже с идеальной конфигурацией транзакции Kafka никогда не охватывают Postgres. Дубликат структурный: запись в БД вне границы транзакции Kafka.
Heads-up read_committed лишь скрывает прерванные записи Kafka от консьюмера; на запись, которую твой код делает в Postgres, он не влияет. БД всё равно нужен свой дедуп.
Heads-up Транзакции у них уже есть. Ни один слой Kafka не дотягивается до Postgres — добавление стоимости Kafka EOS не чинит кросс-системную запись. Чинит дедуп на стороне консьюмера в БД.
Викторина
Completed
У SQS-консьюмера средняя обработка 30с; дефолтный visibility timeout очереди 30с. Инженеры сообщают о спорадической одновременной двойной обработке. Первый фикс и что он даёт?
Heads-up maxReceiveCount=1 отправляет каждый transient-сбой в DLQ на первом промахе; он ничего не делает с окном слишком короткого таймаута и превращает обычные ретраи в расследования poison-pill.
Heads-up Стандартные очереди SQS — at-least-once, и нет переключателя 'exactly-once delivery', побеждающего Two Generals. Фикс корректности — размер таймаута плюс идемпотентный консьюмер.
Heads-up Расширенное значение привязано к этому receipt handle; при передоставке таймаут сбрасывается к дефолту очереди. Надо поднимать сам дефолт очереди или заново слать heartbeat на каждой доставке.
Викторина
Completed
Сервис обновляет Postgres и публикует событие в Kafka двумя отдельными шагами. Под нагрузкой downstream-консьюмеры иногда вообще не видят событие, чья строка в БД явно закоммичена. Какой паттерн чинит первопричину?
Heads-up Idempotent producer предотвращает дубль публикаций; он не может опубликовать событие, которое никогда не было отправлено, потому что процесс умер после коммита БД. Потеря — это разрыв dual-write, который закрывает только транзакционный outbox (или CDC).
Heads-up XA/2PC между Postgres и Kafka хрупок, медленный и редко поддерживается на практике. Outbox достигает той же атомарности, используя только локальную транзакцию БД плюс асинхронный sender.
Heads-up Это dual-write на стороне продюсера Kafka, а не проблема тайминга консьюмера SQS. Visibility timeout не имеет отношения к пропавшей публикации на стороне продюсера.
Итог
Сквозная линия юнита — одна цепочка: exactly-once delivery невозможна (Two Generals), поэтому работаешь по at-least-once и переносишь корректность на консьюмера. Дубликаты концентрируются на плече 3; самая дешёвая защита — INSERT-first транзакционный дедуп, расширенный Idempotency-Key в стиле Stripe для внешних вызовов. Idempotent producer Kafka (~3%) и транзакции (~20–30%) укрепляют только путь внутри Kafka — кросс-системным записям всё равно нужен дедуп консьюмера. SQS visibility timeout должен быть ~6x обработки (или с heartbeat), а паттерн outbox закрывает разрыв dual-write на стороне продюсера. Гарантии брокера необходимы, но никогда не достаточны.