Kaip CDC sinchronizuoja duomenis tarp sistemų?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** srautu ištraukia kiekvieną insert/update/delete iš šaltinio duomenų bazės — dažniausiai **skaitydamas jos transakcijų žurnalą** — ir publikuoja juos kaip įvykius, kuriuos kitos sistemos vartoja, tad downstream saugyklos lieka sinchronizuotos be dual-writes ar apklausų (polling).

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

## Kodėl log pagrindu CDC

Galėtumėte sinchronizuoti apklausdami („eilutės pasikeitė nuo T") arba rašydami į dvi sistemas vienu metu (**dual-write**), bet apklausa praleidžia greitus atnaujinimus, o dual-writes lūžta atomiškai — jei antras įrašymas nepavyksta, gaunate išsiskyrimą. **Log pagrindu CDC** vietoj to seka pačios duomenų bazės write-ahead žurnalą (Postgres **WAL**, MySQL **binlog**), patvarų įrašą, kurį DB naudoja crash recovery. **Debezium** yra standartinis konektorius: jis skaito žurnalą ir publikuoja kiekvieną pokytį į **Kafka**, vieną topic vienai lentelei — pagaudamas *kiekvieną* pokytį be apkrovos užklausoms ir be praleistų eilučių.

## Eiliškumas ir idempotentiškumas

- **Eiliškumas:** pokyčiai tai pačiai eilutei privalo atvykti tvarka, kitaip pritaikytumėte seną reikšmę paskutinę. Kafka garantuoja tvarką **partition viduje**, tad skaidykite pagal pirminį raktą — visi vienos eilutės pokyčiai patenka į vieną partition, commit tvarka.
- **Pristatymas yra at-least-once:** per pakartojimą ar konektoriaus perkrovimą tas pats įvykis gali būti pristatytas dukart. Tad **sinks privalo būti idempotentiški** — raktuokite įrašymą pagal pirminį raktą + log offset (LSN), kad įvykio pakartotinis pritaikymas būtų no-op. Niekada nemanykite exactly-once.

## Interviu perspektyva

Interviuotojas tikrina, ar žinote, kad CDC pranoksta dual-writes ir *kodėl* (atomiškumas, jokių praleistų pokyčių), ir ar suvokiate **at-least-once + idempotentiškus sinks**. Gerai: „Debezium skaito WAL į Kafka." Puikiai: pridedate partition-by-key eiliškumui ir idempotentiškus sinks dublikatams. Spąstai: manyti exactly-once pristatymą arba ignoruoti, kad DDL pokytis šaltinyje gali sulaužyti consumerius.

## Kompromisai ir gedimai

- **Schemos evoliucija:** stulpelio pridėjimas/pašalinimas upstream keičia įvykio formą — naudokite **schema registry** ir suderinamus pokyčius, kad consumeriai nelūžtų.
- **Pradinis snapshot:** CDC mato pokyčius tik *nuo dabar*; jums reikia vienkartinio esamų eilučių snapshot, tada perjungti į srautą.
- **Log saugojimas:** jei šaltinis išvalo žurnalą prieš konektoriui jį perskaitant, prarandate pokyčius — stebėkite konektoriaus lag.
- **Backpressure:** lėtas sink leidžia Kafka lag augti; nustatykite saugojimą ir consumerius piko pokyčių apimčiai.

Kodėl log pagrindu CDC

Eiliškumas ir idempotentiškumas

Interviu perspektyva

Kompromisai ir gedimai

Susiję klausimai