Перейти к содержанию

A. Kafka consumer crash после DB commit до offset commit

Раздел 04 · Failure matrix

Тип материала: учебный архитектурный сценарий. Не описывает систему конкретной компании. Все операции, IDs и числа ниже — HYPOTHETICAL.

Проверка источников: 2026-11-02. Интеграционный fault test этого сценария — NOT_RUN; documented behavior и предлагаемый recovery не считаются выполненным испытанием.

Normal flow

Kafka 4.1, PostgreSQL 17; приложение фиксирует (tenant,event_id,payload_hash) и reporting effect в одной DB transaction. Оно отключает auto-commit offsets и сохраняет следующую позицию только после durable effect. Рассматривается одна partition и serial application; для нескольких futures нужен contiguous frontier.

Нормально запись offset n проходит validation, DB commit и commit n+1. Тот же business event может прийти под другим Kafka offset, поэтому guard использует business ID, а coordinates хранятся для evidence.

Иллюстративная схема нормального пути:

flowchart LR
 K[Read offset n] --> I[Validate identity]
 I --> D[Commit inbox and effect]
 D --> O[Commit offset n plus 1]

Failure timeline

sequenceDiagram
 participant K as Kafka
 participant C as Consumer
 participant D as PostgreSQL
 K->>C: Event at n
 C->>D: Inbox and effect
 D-->>C: COMMIT confirmed
 Note over C: Crash before offset commit
 K->>C: Redeliver n after restart
 C->>D: Same ID and hash
 D-->>C: Saved result, no second effect
 C->>K: Commit n plus 1

Состояние систем после отказа

Участник Durable состояние Неопределённость / проверка
Kafka Stored progress не включает n Вход ещё доступен до retention expiry
PostgreSQL Inbox/effect committed Проверить payload hash и operation result
Consumer Volatile state потерян ACK status в памяти не является authority

Retry и replay

Replay неизбежен и допустим. Guard должен атомарно отличать same identity/same payload от payload conflict. При новом event_id эффект повторится. Commit source offset допустим после подтверждённого duplicate disposition; не нужно выполнять второй debit ради соответствия второму delivery.

Обнаружение проблемы

Сопоставить число attempts и unique committed effects, найти повтор исходных coordinates, проверить duplicate/conflict counters и key-level reconciliation. Простой lag не различает правильную дедупликацию и потерянный effect.

Recovery protocol

  1. Сохранить committed group offsets и DB operation evidence.
  2. Возобновить чтение с последнего durable progress без искусственного skip.
  3. Обработать повтор через inbox transaction и сохранить результат.
  4. Продвинуть только contiguous завершённый prefix.
  5. Сверить identities/amounts и убедиться, что conflict route не был silently acknowledged как applied.

Гарантии и trade-offs

При сохранности DB marker/effect и исходного журнала обеспечивается один reporting effect на identity. Не гарантируются доставка за пределами retention, восстановление после потери DB и exactly-once неидемпотентного HTTP API. Цена — storage inbox, lock contention и повтор чтения.

Практическая проверка

Idempotent consumer lab переиспользует existing SQLite projection как local oracle; Kafka/PG crash test отдельно NOT_RUN. Дополнительно проверьте rollback marker при injected effect failure.

Источники и версии