Kafka retention, compaction и replay¶

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

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

Механизм¶

Delete retention удаляет старые log segments по policy, независимо от того, успели ли все consumers. Compaction оставляет определённое latest per-key представление через cleaner; оно не является немедленной uniqueness и не сохраняет все переходы. Policies delete/compact могут сочетаться.

flowchart TB
  Log[Append log segments] --> Cleaner[Delete or compact policy]
  Cleaner --> Retained[Retained replay scope]
  Retained --> Generation[Isolated replay generation]
  Archive[Verified archive] --> Generation
  Generation --> Reconcile[Reconcile then publish]

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

Append создаёт segments → segment rolls → retention/cleaner обслуживает eligible segments → readers используют сохранённые offsets. Tombstone обозначает удаление key; его retention должен позволять нужному bootstrap reader увидеть delete. Snapshot compacted topic требует протокола согласованного с retained tombstones/cleaner, а не случайного полного scan.

Failure scenarios и recovery¶

Consumer outage дольше retention приводит к offset-out-of-range. auto.offset.reset=earliest не восстанавливает уже удалённое. Replay старых command-like events может повторить внешние эффекты; новая consumer group без new sink generation не безопасный backfill.

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

Archive+manifest расширяет recovery horizon, но требует schema/code/reference-data versions. Полный append history дороже compacted latest state. Compaction не сортирует records по event time и не является Event Sourcing event store со всеми domain facts.

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

Практика: отдельная topic/group/sink generation, freeze source range, replay, сверить keys/amounts, publish pointer. Daily reporting использует тот же принцип generation.

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

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

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

Compaction убирает все дубли сейчас? Нет, cleaner работает асинхронно.

Lag гарантирует доступность backlog? Нет, retention может удалить его до восстановления.

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

Составьте retention matrix Kafka/raw archive/inbox/Redis TTL и укажите, что станет невозможно после каждой границы.