Как CDC синхронизирует данные между системами?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** стримит каждый insert/update/delete из исходной базы данных — обычно **читая её транзакционный лог** — и публикует их как события, которые потребляют другие системы, так что downstream-хранилища остаются синхронными без dual-write или опроса.

```text
  Postgres/MySQL          Debezium            Kafka topic          sinks
 ┌────────────┐  reads   ┌─────────┐  emit   ┌──────────┐  consume ┌───────────┐
 │ WAL/binlog │ ───────▶ │ connector│ ──────▶ │ per-table│ ───────▶ │ search    │
 │ (tx log)   │          │          │  events │  ordered │          │ warehouse │
 └────────────┘          └─────────┘          └──────────┘          │ cache     │
                                                                     └───────────┘
```

## Почему log-based CDC

Вы могли бы синхронизировать опросом («строки, изменённые с момента T») или записью в две системы разом (**dual-write**), но опрос упускает быстрые обновления, а dual-write ломает атомарность — если вторая запись не удалась, вы получаете расхождение. **Log-based CDC** вместо этого читает собственный write-ahead log базы (Postgres **WAL**, MySQL **binlog**) — durable-запись, которую БД использует для crash recovery. **Debezium** — стандартный коннектор: он читает лог и публикует каждое изменение в **Kafka**, один топик на таблицу — захватывая *каждое* изменение без нагрузки на запросы и без пропущенных строк.

## Упорядочивание и идемпотентность

- **Упорядочивание:** изменения одной строки должны приходить по порядку, иначе вы примените старое значение последним. Kafka гарантирует порядок **внутри партиции**, поэтому партиционируйте по primary key — все изменения одной строки попадают на одну партицию, в порядке коммита.
- **Доставка at-least-once:** при повторе или рестарте коннектора одно событие может быть доставлено дважды. Поэтому **sink-и должны быть идемпотентны** — ключуйте запись по primary key + log offset (LSN), чтобы повторное применение события было no-op. Никогда не предполагайте exactly-once.

## Взгляд с точки зрения интервью

Интервьюер проверяет, знаете ли вы, что CDC побеждает dual-write и *почему* (атомарность, отсутствие пропущенных изменений), и понимаете ли **at-least-once + идемпотентные sink-и**. Хорошо: «Debezium читает WAL в Kafka». Отлично: вы добавляете partition-by-key для упорядочивания и идемпотентные sink-и для дублей. Ловушка: считать доставку exactly-once или игнорировать, что DDL-изменение на источнике может сломать потребителей.

## Компромиссы и режимы отказа

- **Эволюция схемы:** добавленная/удалённая колонка upstream меняет форму события — используйте **schema registry** и совместимые изменения, чтобы потребители не ломались.
- **Начальный снапшот:** CDC видит изменения только *с этого момента*; вам нужен разовый снапшот существующих строк, затем переключение на стриминг.
- **Retention лога:** если источник вычищает лог до того, как коннектор его прочитал, вы теряете изменения — мониторьте lag коннектора.
- **Backpressure:** медленный sink даёт lag Kafka расти; задавайте retention и потребителей под пиковый объём изменений.

Почему log-based CDC

Упорядочивание и идемпотентность

Взгляд с точки зрения интервью

Компромиссы и режимы отказа

Похожие вопросы