Kafka

PHẦN A — MESSAGE QUEUE Câu 1 — [Intermediate → Senior] Kafka hoạt động thế nào? Tại sao nó đạt throughput hàng triệu message/giây? 1. Câu hỏi “Kiến trúc Kafka: topic, partition, consumer group, offset. Điều gì cho phép Kafka nhanh như vậy trên phần cứng thường?” 2. Interviewer muốn kiểm tra điều gì? Hiểu Kafka là distributed log, không phải message queue truyền thống — khác biệt định hình mọi tính chất. Giải thích được nguồn hiệu năng bằng cơ chế cụ thể (sequential I/O, zero-copy, batching), không phải “Kafka nhanh vì được thiết kế tốt”. Nắm ordering, rebalance, lag — các khái niệm vận hành hằng ngày. 3. Câu trả lời ngắn gọn (30 giây) “Kafka là log phân tán: topic chia thành partition, mỗi partition là file log append-only có thứ tự; message không bị xóa khi đọc mà giữ theo retention; consumer tự quản offset của mình. Consumer group chia partition cho các consumer — scale đọc bằng cách thêm consumer tới tối đa = số partition. Nhanh nhờ: ghi/đọc tuần tự trên đĩa (nhanh gần bằng RAM, tận dụng page cache OS), zero-copy (sendfile — dữ liệu từ page cache thẳng ra socket không qua user space), batching + nén cả lô, và broker cực kỳ ’ngu’ — không track trạng thái từng message như RabbitMQ, chỉ là cái log có index.” ...

Tốc độ Kafka đến từ bốn quyết định thiết kế cộng hưởng, không phải một mẹo. 1. Ghi tuần tự (sequential write) Trực giác sai: “ghi đĩa chậm, phải dùng RAM”. Thực tế: ghi đĩa tuần tự nhanh hơn ghi RAM ngẫu nhiên. Random access (DB cập nhật chỗ này chỗ kia): tốn seek, chậm cả HDD lẫn SSD. Sequential write: chỉ ghi nối tiếp vào cuối file, không seek — HDD ~100s MB/s, SSD cao hơn. Kafka chọn log append-only: message mới luôn ghi vào cuối, không sửa/chèn. Đây là lý do sâu xa Kafka không cho xóa/sửa message — ràng buộc có chủ đích để đổi lấy tốc độ. ...

Outbox Pattern — giải bài toán “dual write” Service order phải ghi vào DB và bắn event lên Kafka. Làm tuần tự thì luôn có khe hở: ghi DB OK -> bắn Kafka FAIL => DB có đơn, hệ thống khác không biết (lệch) bắn Kafka OK -> ghi DB FAIL => event bắn rồi nhưng đơn không tồn tại (ma)Hai hệ thống khác nhau không chia sẻ transaction → không thể “cùng thành công hoặc cùng thất bại” trực tiếp. ...

Mọi tinh chỉnh là đánh đổi giữa throughput (số lượng/giây), latency (độ trễ mỗi message), và durability. Không có nút “nhanh hơn” miễn phí. Phía Producer — gom để nhanh linger.ms + batch.size (cặp quan trọng nhất). Mặc định linger.ms=0 = gửi ngay từng message → nhiều request nhỏ. Tăng linger.ms (5–20ms) cho producer chờ gom batch rồi gửi một lần. batch.size (mặc định 16KB) là trần mỗi batch. ...

Vấn đề Topic được nhiều team ghi/đọc. Một ngày team A đổi cấu trúc message (đổi tên field, đổi kiểu, bỏ field) → consumer của B, C, D vỡ ngay, thường lúc 2h sáng. JSON tự do có 3 điểm yếu ở quy mô lớn: không có schema bắt buộc, tốn băng thông (lặp tên field), không kiểm soát thay đổi. Schema Registry hoạt động thế nào Service riêng lưu và đánh version cho schema: ...

Triết lý: fail gracefully, đừng fail catastrophically. Một message hỏng là chuyện bình thường; mục tiêu là nó không kéo cả partition/hệ thống sập. Hai loại lỗi — phân biệt được mới xử lý đúng Tạm thời (transient): DB timeout, API phụ thuộc down, mạng chập chờn. → retry sẽ qua. Vĩnh viễn (permanent / “poison”): sai format, thiếu field, vi phạm nghiệp vụ. → retry vô ích, đẩy đi chỗ khác. Ánh xạ HTTP status hữu ích: ...

Vấn đề 1 — Duplicate do PRODUCER retry Producer gửi message, broker đã ghi thành công nhưng gói ACK rớt trên đường về. Producer tưởng thất bại → retry → broker ghi lần hai. Message nằm 2 lần trong log dù bạn làm đúng mọi thứ. (Khác với duplicate phía consumer ở Bài 4.) Giải pháp — Idempotent Producer enable.idempotence=true: broker cấp mỗi producer một PID và mỗi message một sequence number theo partition. Retry mang sequence đã thấy → broker lặng lẽ bỏ qua. Thêm bảo đảm thứ tự không bị đảo khi retry. ...

Replica, Leader, Follower Mỗi partition có N bản sao (replication-factor): 1 leader: phục vụ mọi đọc/ghi của client. N-1 follower: liên tục kéo dữ liệu từ leader để bắt kịp. Ẩn với client. Client chỉ làm việc với leader. Follower chỉ để chống mất dữ liệu khi broker chứa leader chết. ISR (In-Sync Replicas) Tập các replica đang theo kịp leader (gồm cả leader). Follower tụt quá replica.lag.time.max.ms (~30s) bị đá khỏi ISR. Khi leader chết, Kafka chỉ bầu leader mới từ trong ISR (vì chỉ chúng chắc chắn có đủ dữ liệu đã xác nhận). ...

Bài quan trọng nhất về độ tin cậy. Hầu hết bug “mất message” / “xử lý trùng” ở production nằm ở đây. Offset commit là gì? Consumer cần báo cho Kafka biết đã xử lý đến đâu, để lần sau (hoặc consumer khác sau rebalance) đọc tiếp đúng chỗ. Việc đó gọi là commit offset, lưu trong topic nội bộ __consumer_offsets. Mấu chốt sinh ra mọi vấn đề: xử lý message và commit offset là hai hành động riêng biệt, giữa chúng consumer có thể crash. Thứ tự hai hành động này quyết định “delivery semantics”. ...

Producer chọn partition thế nào? Có key: partition = hash(key) % số_partition. Cùng key + số partition không đổi → luôn cùng partition → giữ thứ tự. Không key: rải đều (sticky/round-robin), tối ưu throughput nhưng không đảm bảo thứ tự. Ba cạm bẫy quanh partitioning Bẫy 1 — Hàm hash khác nhau giữa các client Client Java dùng murmur2; librdkafka (confluent-kafka-go, Python, C…) mặc định dùng thuật toán khác (consistent_random, nền CRC32). → Cùng một key, producer Java và producer Go có thể đẩy vào hai partition khác nhau! ...

Khái niệm Consumer group là tập các consumer cùng group.id, hợp sức tiêu thụ một topic. Kafka tự chia partition cho các thành viên — gọi là partition assignment. Quan hệ then chốt: Trong 1 group: 1 partition -> tối đa 1 consumer (KHÔNG phải 1-n) 1 consumer -> có thể N partition Trên nhiều group: 1 partition -> N consumer (mỗi group 1 đứa) (pub/sub)Hệ quả thực chiến: số consumer hữu ích tối đa trong một group = số partition. Topic 3 partition, group 5 consumer → 3 đứa làm việc, 2 đứa ngồi không. Partition là trần scale của consumer — muốn xử lý song song hơn phải tăng partition trước. ...

Khái niệm nền tảng Topic là một “kênh” logic chứa message, ví dụ orders chứa các sự kiện đơn hàng. Partition là điểm mấu chốt phân biệt Kafka với hàng đợi thường. Mỗi topic được chia thành nhiều partition. Mỗi partition là một log ghi nối tiếp (append-only): message có thứ tự tuyệt đối trong partition, và mỗi message mang một số thứ tự gọi là offset (0, 1, 2, …). ...

Chương cuối này là phần “chưng cất” của toàn bộ tài liệu. Sau mười hai chương về cơ chế, pattern, sự cố và kiến trúc, câu hỏi còn lại rất thực dụng: làm gì, tránh gì, và — quan trọng không kém — khi nào đừng làm cả. Tôi cố tình viết chương này theo kiểu có thể in ra dán cạnh bàn on-call: mỗi practice kèm lý do, mỗi anti-pattern kèm hậu quả thật, vì quy tắc không có lý do sẽ bị bỏ qua ngay lần deadline đầu tiên. ...

Hai chương trước cho bạn pattern (chương 10) và bản đồ rủi ro (chương 11). Chương này ghép chúng lại thành thiết kế hoàn chỉnh theo từng loại hệ thống. Cùng một công nghệ — Debezium, Kafka — nhưng bài toán e-commerce, FinTech hay SaaS multi-tenant dẫn đến những quyết định rất khác nhau, và điều làm nên một Solution Architect giỏi không phải là biết công cụ, mà là biết bối cảnh nào bẻ cong thiết kế theo hướng nào. ...

Đây là chương quan trọng nhất của toàn bộ tài liệu. Lý do rất đơn giản: CDC không khó ở lúc setup — CDC khó ở tháng thứ ba vận hành. Demo Debezium chạy trong một buổi chiều; nhưng pipeline CDC production là một chuỗi hệ thống stateful nối tiếp nhau (database → connector → Kafka → consumer → sink), và mỗi mắt xích có những chế độ hỏng riêng, đôi khi âm thầm, đôi khi phá hủy cả database nguồn. ...

Đến chương này, chúng ta đã hiểu CDC hoạt động thế nào ở tầng cơ chế: transaction log, replication slot, connector, offset. Câu hỏi tiếp theo — và là câu hỏi mà một Tech Lead hay Solution Architect thực sự phải trả lời — là: CDC đứng ở đâu trong kiến trúc tổng thể? Nó thay thế cái gì, kết hợp với pattern nào, và quan trọng hơn: nó không phải là cái gì. ...

Hai chương trước cho bạn nguồn (Debezium) và nền tảng (Kafka Connect). Chương này lắp mọi thứ thành pipeline hoàn chỉnh — và quan trọng hơn, chỉ ra các quyết định thiết kế ở giữa hai đầu: topic và partition, schema contract, cách từng loại đích tiêu hóa change event, và latency/backpressure của toàn tuyến. Kinh nghiệm của tôi: pipeline CDC thất bại ở production hiếm khi vì Debezium hay Kafka lỗi — nó thất bại vì các quyết định thiết kế trung gian bị bỏ qua: topic 200 partition cho bảng 50 nghìn row, JSON không schema, insert từng row vào ClickHouse. Cuối chương có đúng ví dụ đó, kèm bản chữa. ...

Chương 7 kết thúc với một nhận định: phần khó nhất của CDC không phải đọc log mà là quản lý trạng thái và fault tolerance — và Debezium đẩy toàn bộ phần đó cho Kafka Connect. Chương này mở hộp đen Kafka Connect từ góc nhìn người vận hành platform. Nếu Debezium là động cơ, Connect là khung gầm: khi pipeline CDC gặp sự cố lúc 3 giờ sáng, thứ bạn thao tác gần như luôn là Connect — REST API, task state, rebalance, internal topic — chứ không phải code Debezium. ...

Ở các chương trước, chúng ta đã phân tích cơ chế log-based CDC ở tầng database: WAL của PostgreSQL, binlog của MySQL, replication slot, logical decoding. Chương này đi vào bên trong Debezium — thành phần đứng giữa database và Kafka — để trả lời câu hỏi mà mọi kiến trúc sư phải trả lời được trước khi đưa Debezium vào production: nó thực sự làm gì bên trong, trạng thái của nó nằm ở đâu, và điều gì xảy ra khi nó chết? ...

Đối tượng: Senior Backend Engineer, Tech Lead, Solution Architect thiết kế pipeline CDC end-to-end. Mục tiêu chương: Hai chương trước đi sâu vào từng nguồn log. Chương này trả lời câu hỏi ở tầng trên: bất kể nguồn là WAL, binlog hay oplog, một CDC connector phải giải năm bài toán bất biến: (1) dựng trạng thái ban đầu khi log không giữ toàn bộ lịch sử; (2) nhớ vị trí đọc để crash không chết pipeline; (3) đảm bảo gì về delivery; (4) đảm bảo gì về thứ tự; (5) sống sót qua schema change. Ai nắm năm bài toán này sẽ đánh giá được mọi công cụ CDC — Debezium hay bất cứ tên nào xuất hiện sau này — bằng cùng một checklist. ...

Đối tượng: Senior Backend Engineer, Tech Lead, Solution Architect vận hành CDC trên MySQL và MongoDB. Mục tiêu chương: Chương 4 đã mổ xẻ WAL của PostgreSQL. Chương này áp cùng khung tư duy lên hai họ database còn lại chiếm phần lớn thị phần CDC: MySQL (binlog) và MongoDB (oplog). Điểm mấu chốt không phải là học ba bộ thuật ngữ — mà là nhận ra ba hệ đã chọn ba mô hình retention và contract khác nhau cho cùng một bài toán, và mỗi lựa chọn sinh ra một failure mode đặc trưng mà bạn, người thiết kế platform, phải phòng thủ theo cách khác nhau. ...

Đối tượng: Senior Backend Engineer, Tech Lead, Solution Architect đang thiết kế hoặc vận hành pipeline CDC trên PostgreSQL. Mục tiêu chương: Sau chương này, bạn phải trả lời được ba câu hỏi mà mọi cuộc review kiến trúc CDC trên PostgreSQL đều xoay quanh: (1) WAL thực chất là gì và vì sao nó là nguồn sự thật duy nhất mà CDC có thể tin; (2) replication slot hoạt động thế nào và vì sao nó là con dao hai lưỡi nổi tiếng nhất của CDC trên PostgreSQL; (3) REPLICA IDENTITY ảnh hưởng gì đến nội dung event và bạn phải trả giá gì cho từng lựa chọn. ...

3.1. Insight nền tảng: dữ liệu về mọi thay đổi đã tồn tại sẵn Hãy quay lại điểm mà Chương 2 dừng lại. Chúng ta cần một nguồn thông tin về thay đổi thỏa mãn ba điều kiện: đầy đủ tuyệt đối (mọi thay đổi, từ mọi đường ghi, kể cả DELETE), atomic với dữ liệu commit (không event ma, không mất event), và không đặt thêm chi phí vào transaction path. ...

Chương 1 đã xác lập bài toán: dữ liệu buộc phải phân mảnh theo workload, và cần một cơ chế đưa thay đổi từ source of truth đến các hệ thống downstream. Chương này đi qua các phương pháp mà ngành đã dùng suốt ba thập kỷ — theo đúng thứ tự tiến hóa của chúng. Đây không phải bài điểm danh lịch sử: mỗi phương pháp vẫn đang chạy trong production ở đâu đó ngay lúc này, và mỗi phương pháp đều dạy ta một bài học về vì sao CDC log-based cuối cùng trở thành câu trả lời. Với mỗi phương pháp, ta phân tích theo cùng một template: cách hoạt động, ưu điểm, hạn chế kỹ thuật, một ví dụ production khi nó fail, và — quan trọng không kém — khi nào nó vẫn là lựa chọn đúng. ...

1.1. Bắt đầu từ một bài toán kinh doanh cụ thể Hãy hình dung một hệ thống e-commerce cỡ vừa: 5 triệu người dùng, 2 triệu SKU, khoảng 300.000 đơn hàng mỗi ngày. PostgreSQL là source of truth — nơi mọi transaction ghi đơn, trừ kho, cập nhật giá diễn ra. Hệ thống chạy tốt trong hai năm đầu. Rồi các yêu cầu sau lần lượt xuất hiện: Search: người dùng cần tìm kiếm sản phẩm theo full-text, fuzzy matching, faceted filter theo thương hiệu, khoảng giá, đánh giá. Đội ngũ chọn Elasticsearch. Analytics: đội business cần dashboard doanh thu theo giờ, phân tích cohort, funnel conversion trên hàng trăm triệu event. Đội data chọn ClickHouse. Cache: trang chi tiết sản phẩm chịu 20.000 request/giây lúc flash sale, không thể đánh thẳng vào PostgreSQL. Đội backend đặt Redis phía trước. Đến đây, cùng một thực thể product tồn tại ở bốn nơi: PostgreSQL (bản gốc), Elasticsearch (bản đánh index cho search), ClickHouse (bản denormalized cho analytics), Redis (bản serialized cho cache). Dữ liệu đã bị phân mảnh (data fragmentation). Và câu hỏi trung tâm của toàn bộ tài liệu này xuất hiện: ...

Bộ tài liệu chuyên sâu về Change Data Capture (CDC) — viết từ góc nhìn của người thiết kế Data Platform và Distributed Systems, không phải từ góc nhìn người dùng công cụ. Đối tượng: Backend Engineer, Data Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Triết lý trình bày: Business Problem → Vì sao cần đồng bộ dữ liệu → Hạn chế của Polling → Trigger / Dual Write / Event Publishing → CDC → Log-based CDC → Internal Architecture → Trade-off → Production → Khi nào không nên dùng CDC. ...