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

H. Kafka rebalance при in-flight messages

Раздел 04 · Failure matrix

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

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

Normal flow

Kafka 4.1, manual commits, per-partition bounded workers. Polling, assignment и business execution имеют разные lifecycle. При normal processing consumer отправляет offset следующей записи только после непрерывно завершённого префикса. Новое assignment не делает прежние DB requests физически отменёнными.

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

flowchart LR
 P[Poll assigned partition] --> Q[Bounded per-partition queue]
 Q --> D[Durable guarded DB effect]
 D --> F[Contiguous completion frontier]
 F --> C[Commit next offset with valid ownership]

Failure timeline

sequenceDiagram
 participant A as Old consumer
 participant K as Group coordinator
 participant B as New consumer
 participant D as Database
 A->>D: In-flight operation at n
 K-->>A: Revoke partition
 K-->>B: Assign partition from durable offset
 B->>D: Replay operation n
 D-->>A: Old request may still finish
 D-->>B: Unique identity prevents second effect
 B->>K: Commit contiguous next offset

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

Участник Durable состояние Неопределённость / проверка
Coordinator Assignment меняется по group protocol Old generation commit может быть rejected
Old worker Volatile queues/request ещё живы Cancellation future не доказывает отмену DB write
DB Old/new requests могут конкурировать Constraint и payload check защищают effect
New worker Читает с durable committed frontier Не начинать после max fetched offset

Retry и replay

После revoke старый handler прекращает новые submissions и commits по потерянной ownership, но незавершённый external request может завершиться. Новый worker читает повтор и использует тот же business ID. Для delta sequencing нужны per-entity guards, одной dedup недостаточно.

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

Собрать assignment/revocation logs с member/generation, poll latency, commit errors, in-flight counts и DB duplicates. Lag и частые rebalances указывают на overload, но не доказывают, что данные потеряны. Проверить holes в committed prefix.

Recovery protocol

  1. На revoke остановить intake затронутых partitions, ограниченно drain/cancel queue согласно client protocol.
  2. Сохранять прогресс только для завершённого непрерывного prefix и действующего assignment.
  3. При rejected commit не искусственно продвигать offset; разрешить replay новому владельцу.
  4. Все старые/новые writes защищать durable identities и business revision.
  5. Настроить poll servicing, max in-flight и backpressure; проверить client-specific rebalance callbacks.
  6. Сверить identity sets и out-of-order effects после стабилизации group.

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

Group ownership защищает распределение чтения, но не fencing внешней БД. Inbox обеспечивает duplicate-safe эффект при сохранности marker/effect. Ordered business effects требуют дополнительного sequencer. Реальные rebalance interleavings и failure callbacks NOT_RUN.

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

В offset replay lab используйте два consumer instances и задержку effect в lab harness; покажите old/new collision и отсутствие второго effect. Не коммитьте max завершённый offset через gap.

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