Backpressure, retry, ordering и poison messages¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Версии в источниках: Kafka/Connect/Streams 4.1, Debezium 3.3, Flink 1.20.3, Spark 4.0.1 и Airflow 3.1 либо явно названная система. Непроверенные вопросы и ограничения runtime — в журнале (архив рабочего проекта).

Механизм¶

Backpressure ограничивает скорость upstream при перегрузке downstream; retry повторяет попытку, ordering задаёт допустимую последовательность. Poison record не исправится от бесконечного retry и может блокировать целую partition или занимать все workers.

flowchart TB
  Record --> Validate[Validate and classify]
  Validate --> Effect[Durable idempotent effect]
  Validate --> Retry[Bounded transient retry]
  Retry --> Effect
  Validate --> DLQ[Confirmed quarantine]
  Effect --> Offset[Advance safe prefix]
  DLQ --> Offset

Пошаговое объяснение¶

Validate input → classify permanent/transient → bounded retry с backoff/deadline → commit durable effect либо durable quarantine → только затем advance source progress. При retry-topic routing меняется порядок: более позднее событие может обойти раннее, поэтому нужны business versions либо остановка key/partition.

Failure scenarios и recovery¶

SQL commit + lost ACK вызывает replay; target idempotency сохраняет effect. DLQ send + lost ACK может дать несколько quarantine records. Если send не подтверждён, commit source offset опасен. Consumer не должен продолжить и commit более поздний offset той же partition после необработанной ранней ошибки.

Trade-offs и эксплуатация¶

Pause partition сохраняет order ценой blocking unrelated keys; retry topics повышают availability ценой reordering/extra state. Global sleep тормозит все partitions и poll loop. max.poll.interval и retry budget должны быть согласованы; не лечить overload бесконечными speculative retries.

Практический пример¶

DLQ/retry consumer показывает sequential safe prefix, bounded SQLite transient retries и confirmed quarantine publication. Это не универсальная библиотека всех brokers.

Типичные ошибки проектирования¶

Смешивать source/state/sink boundaries, скрывать failed records и неопределённый исход timeout; применять retry без identity/version и retention contract. Конкретные ограничения разобраны выше.

Вопросы на собеседовании¶

DLQ гарантирует исправление? Нет, это наблюдаемый backlog с owner.

Можно commit после enqueue в producer buffer? Нет, нужно знать outcome durable publication по выбранному broker contract.

Практические упражнения¶

Разберите poison offset11 и valid12; предложите strict-order и retry-topic варианты, указав последствия каждой схемы.