Bagaimana CDC men-sync data merentas sistem?

Question

IT Interview Practice · Accepted Answer

**Change Data Capture (CDC)** mengalirkan setiap insert/update/delete keluar dari database sumber — biasanya dengan **membaca transaction log-nya** — dan menerbitkannya sebagai peristiwa yang dikonsumsi oleh sistem lain, supaya store hiliran kekal segerak tanpa dual-write atau polling.

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

## Mengapa log-based CDC

Anda boleh men-sync dengan polling ("baris berubah sejak T") atau dengan menulis ke dua sistem sekaligus (**dual-write**), tetapi polling terlepas kemas kini pantas dan dual-write pecah secara atomik — jika penulisan kedua gagal anda mendapat penyimpangan. **Log-based CDC** sebaliknya mengekori write-ahead log database itu sendiri (Postgres **WAL**, MySQL **binlog**), rekod durable yang digunakan DB untuk crash recovery. **Debezium** ialah connector standard: ia membaca log dan menerbitkan setiap perubahan ke **Kafka**, satu topic bagi setiap jadual — menangkap *setiap* perubahan tanpa beban pada query dan tanpa baris terlepas.

## Penyusunan & idempotency

- **Penyusunan (ordering):** perubahan pada baris yang sama mesti tiba dalam urutan atau anda akan mengaplikasi nilai lama terakhir. Kafka menjamin urutan **dalam satu partition**, jadi partition mengikut primary key — semua perubahan untuk satu baris mendarat pada satu partition, dalam urutan commit.
- **Penghantaran adalah at-least-once:** pada retry atau restart connector peristiwa yang sama boleh dihantar dua kali. Jadi **sink mesti idempotent** — kunci penulisan mengikut primary key + log offset (LSN) supaya mengaplikasi semula sebuah peristiwa ialah no-op. Jangan sekali-kali anggap exactly-once.

## Perspektif temu duga

Penemu duga menyemak sama ada anda tahu CDC mengalahkan dual-write dan *mengapa* (keatoman, tiada perubahan terlepas), dan sama ada anda memahami **at-least-once + idempotent sink**. Baik: "Debezium membaca WAL ke dalam Kafka." Hebat: anda menambah partition-by-key untuk penyusunan dan idempotent sink untuk pendua. Perangkap: menganggap penghantaran exactly-once, atau mengabaikan bahawa perubahan DDL pada sumber boleh memecahkan consumer.

## Pertukaran & mod kegagalan

- **Evolusi schema:** satu lajur ditambah/digugurkan di hulu mengubah bentuk peristiwa — guna sebuah **schema registry** dan perubahan serasi supaya consumer tidak pecah.
- **Snapshot awal:** CDC hanya melihat perubahan *dari sekarang*; anda perlukan snapshot sekali-sahaja bagi baris sedia ada, kemudian bertukar ke streaming.
- **Retention log:** jika sumber membersihkan log-nya sebelum connector membacanya, anda kehilangan perubahan — pantau connector lag.
- **Backpressure:** sebuah sink perlahan membenarkan Kafka lag membesar; saiz retention dan consumer untuk volum perubahan puncak.

Mengapa log-based CDC

Penyusunan & idempotency

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan