Bài 1: Debezium là gì? Giải ngố về Change Data Capture (CDC) cho người mới

1. Vấn đề muôn thuở của các hệ thống lớn

Hãy tưởng tượng bạn đang phát triển một ứng dụng thương mại điện tử. Ban đầu, mọi thứ thật đơn giản: User mua hàng -> Lưu vào Database (MySQL/PostgreSQL).

Nhưng khi hệ thống lớn lên, bạn nhận ra:

• Cần tìm kiếm sản phẩm nhanh hơn -> Phải đồng bộ dữ liệu từ DB sang Elasticsearch.
• Cần hiển thị giỏ hàng ngay lập tức -> Phải lưu một bản sao dữ liệu vào Redis (Cache).
• Đội Data muốn lấy thông tin đơn hàng để vẽ biểu đồ phân tích -> Phải đẩy dữ liệu sang Data Warehouse.

Câu hỏi đặt ra là: Làm sao để báo cho các hệ thống khác biết mỗi khi Database chính có dữ liệu mới (Insert) hoặc bị thay đổi (Update, Delete)?

Theo cách truyền thống, chúng ta thường làm:

• Cách 1 - Dual Write (Ghi nhiều nơi): Khi code lưu đơn hàng vào DB, viết thêm code gọi API lưu luôn vào Elasticsearch và Redis.
  • Hậu quả: Code phình to, chậm. Nếu lưu DB thành công nhưng gọi API sang Elasticsearch bị lỗi mạng thì dữ liệu sẽ bị lệch.
• Cách 2 - Polling (Hỏi thăm liên tục): Viết một con cronjob, cứ 1 phút lại query vào DB hỏi "Có bản ghi nào mới cập nhật không?".
  • Hậu quả: Quá tải Database nếu dữ liệu lớn, thời gian thực (real-time) bị kém.

Chúng ta cần một giải pháp thông minh hơn. Đó là lúc CDC và Debezium xuất hiện.

2. CDC (Change Data Capture) là gì?

Hãy tưởng tượng Database của bạn là một cái kho hàng, và mọi hành động nhập/xuất kho đều được ghi vào một cuốn sổ nhật ký (Transaction Log - như binlog trong MySQL hay WAL trong PostgreSQL).

Thay vì cứ 5 phút lại chạy vào kho đếm lại hàng (Polling), CDC hoạt động giống như một chiếc camera giám sát cuốn sổ nhật ký. Bất cứ khi nào thủ kho đặt bút ghi một dòng mới (Insert/Update/Delete), camera sẽ ngay lập tức chụp lại và báo qua bộ đàm cho những người cần biết.

Nhờ vậy, CDC giúp lấy được sự thay đổi dữ liệu theo thời gian thực (real-time) mà không cần phải query trực tiếp vào các bảng dữ liệu, không làm chậm Database chính.

3. Vậy Debezium là gì?

Debezium chính là "chiếc camera giám sát" xịn sò nhất hiện nay để làm nhiệm vụ CDC.

• Về mặt kỹ thuật: Debezium là một nền tảng mã nguồn mở phân tán (mũi nhọn của Red Hat), được xây dựng trên nền tảng của Apache Kafka.
• Cách Debezium hoạt động (Rất đơn giản):
  1. Debezium kết nối vào Database của bạn (MySQL, PostgreSQL, MongoDB, SQL Server...).
  2. Nó âm thầm đọc các file log (Transaction log) ở mức low-level.
  3. Khi phát hiện có sự thay đổi (VD: UPDATE users SET status = 'active'), nó sẽ đóng gói sự kiện này thành một message.
  4. Nó đẩy message đó vào Apache Kafka (hoặc các Message Broker tương tự).
  5. Các hệ thống khác (Elasticsearch, Redis, Microservices khác) chỉ việc ngồi "hóng" (subscribe) trên Kafka để lấy dữ liệu về xử lý một cách độc lập.

4. Tại sao người ta lại "phát cuồng" vì Debezium?

Nếu bạn làm việc với kiến trúc Microservices, Debezium là một "vũ khí hạng nặng" vì những ưu điểm sau:

• Không làm chậm Database: Vì Debezium chỉ đọc file log trên ổ cứng, nó không thực hiện các câu query SELECT nặng nề, nên Database của bạn vẫn chạy mượt mà.
• Thời gian thực (Real-time): Độ trễ thường chỉ tính bằng mili-giây. Dữ liệu đổi ở DB là Kafka có message ngay.
• Đảm bảo tính nhất quán (Consistency): Bắt được mọi thay đổi, kể cả khi ai đó vào trực tiếp Database bằng tool (như DBeaver/Navicat) để sửa tay, Debezium vẫn bắt được hết (điều mà code ở tầng Application không làm được).
• Đảm bảo thứ tự: Sự kiện Insert xảy ra trước Update sẽ luôn được Debezium đẩy đi đúng theo thứ tự đó.

5. Tổng kết

Ở bài này, bạn chỉ cần nhớ một điều cốt lõi: Debezium là một công cụ giúp đọc các thay đổi từ Database một cách âm thầm thông qua file log (CDC) và đẩy nó ra ngoài (thường là Kafka) theo thời gian thực.

Bài tiếp theo: Chúng ta đã hiểu lý thuyết, ở Bài 2, chúng ta sẽ xắn tay áo lên tìm hiểu Kiến trúc tổng thể của một hệ thống có Debezium, và chạy thử nghiệm nó lên máy local bằng Docker Compose nhé!