Kafka thực chiến cho backend

Sê-ri 12 phần về Apache Kafka dưới góc nhìn lập trình viên backend: không chỉ lý thuyết mà DỰNG BROKER THẬT (KRaft single-node trong Docker) và ĐO THẬT — throughput, partition parallelism, consumer group rebalance, delivery semantics, offset, consumer lag, batching/compression, retention/compaction, replication/ISR, serialization, outbox pattern. Mỗi bài giải thích cơ chế rồi chứng minh bằng số liệu đo được, nêu rõ đánh đổi.

10/12 phần đã đăng Lập trình

1 Kafka cho backend từ con số 0: vì sao nó là cuốn sổ ghi, không phải hàng đợi — và nửa triệu message/giây trên một node Nhiều người tưởng Kafka là một message queue nhanh hơn. Hiểu vậy là bỏ lỡ điểm cốt lõi: Kafka là một append-only log — message không bị xoá sau khi đọc, nhiều consumer đọc độc lập, và đọc lại được từ đầu. Bài mở màn sê-ri dựng broker KRaft single-node thật trong Docker, produce/consume, chứng minh log không mất bằng cách consume hai lần, và đo throughput thật: 527.983 bản ghi/giây (50 MB/giây) trên đúng một node. 22/09/2026 · 7 phút đọc 2 Partition trong Kafka: vì sao key quyết định thứ tự, và 6 partition cho throughput gấp đôi Partition là đơn vị song song của Kafka — nhưng nó cũng là nơi mọi hiểu lầm về thứ tự bắt đầu. Bài này đo thật trong lab: cùng một key luôn rơi vào cùng một partition (nên sự kiện của một user giữ đúng thứ tự), nhưng Kafka KHÔNG đảm bảo thứ tự giữa các partition. Rồi so throughput 1 partition (580k/giây) với 6 partition (1,22 triệu/giây) để thấy song song hoá thật sự, kèm cái bẫy phân bố lệch khi ít key. 22/09/2026 · 6 phút đọc 3 Consumer group và rebalance: cách Kafka chia việc cho nhiều worker, và vì sao consumer thứ tư ngồi không Partition cho Kafka khả năng song song; consumer group là cách bạn khai thác nó. Bài này đo thật trong lab: một group với 1 consumer ôm cả 3 partition, thêm consumer thứ hai thì Kafka chia lại 2+1, thứ ba thì mỗi consumer đúng một partition, và consumer thứ tư ngồi không vì chỉ có 3 partition. Hiểu rebalance để co giãn số worker theo tải — và biết cái giá stop-the-world của nó. 22/09/2026 · 6 phút đọc 4 Delivery semantics trong Kafka: at-most-once, at-least-once, exactly-once — và vì sao acks=0 lại chậm hơn Message của bạn có thể bị mất, bị trùng, hoặc được ghi đúng một lần — ba kịch bản này do acks và idempotence quyết định. Bài này giải thích cơ chế từng mức rồi đo thật throughput theo acks trên lab, kèm hai phát hiện trung thực: trên single-node acks=all gần như acks=1 về độ bền, và acks=0 (gửi rồi quên) lại CHẬM hơn acks=1 — ngược hẳn trực giác. Idempotent producer thì gần như miễn phí. 22/09/2026 · 6 phút đọc 5 Offset trong Kafka: cái bookmark quyết định mất hay trùng dữ liệu, và cách tua lại log Consumer nhớ đã đọc tới đâu bằng committed offset — và chính chỗ bạn đặt lệnh commit quyết định hệ thống mất dữ liệu hay xử lý trùng khi crash. Bài này đo thật: đọc 100 message rồi xem CURRENT-OFFSET/LOG-END-OFFSET/LAG, rồi tua lại log bằng reset-offsets (về đầu đọc lại 100, tới offset 50 đọc 50, lùi 20 đọc 20). Và vì sao auto-commit tiện nhưng âm thầm làm mất message. 22/09/2026 · 6 phút đọc 6 Consumer lag: con số nói cho bạn biết hệ thống Kafka sắp sập trước khi nó sập Nếu chỉ được theo dõi một chỉ số của Kafka, hãy chọn consumer lag — khoảng cách giữa chỗ producer đã ghi và chỗ consumer đã xử lý. Bài này đo thật trong lab: lag phình từ 700 lên 1200 khi producer ghi nhanh hơn consumer, rồi co về 0 khi consumer đuổi kịp. Hiểu công thức LAG = LOG-END − CURRENT, phân biệt offset lag với time lag, và biết dấu hiệu nguy hiểm thật: lag tăng đều không ngừng. 22/09/2026 · 6 phút đọc 7 Tối ưu throughput producer Kafka: batch, linger và nén — khi lz4 vừa nhanh hơn vừa nhỏ 24 lần Producer Kafka mặc định đã nhanh, nhưng chỉnh đúng ba núm là tăng gấp đôi. Bài này đo thật trong lab: gom batch 128KB + linger 10ms cho throughput 2,25 lần (118 lên 266 MB/s) và độ trễ còn thấp hơn; nén lz4 vừa nhanh hơn không nén vừa nhỏ 24 lần trên đĩa, zstd nén tới 58 lần (26MB còn 460KB). Và vì sao đẩy batch quá to lại phản tác dụng. 22/09/2026 · 6 phút đọc 8 Retention và log compaction trong Kafka: xoá theo tuổi hay giữ bản mới nhất mỗi key Kafka giữ log nhưng không giữ mãi — cleanup.policy quyết định số phận dữ liệu. Bài này đo thật log compaction trong lab: một topic nhận 8 message cho 3 key, sau compaction chỉ còn value mới nhất mỗi key (user-A từ 4 bản 100/120/200/180 còn đúng 180), và offset được giữ nguyên không đánh số lại. Giải thích retention theo thời gian/dung lượng, vì sao broker quét định kỳ, và khi nào compaction biến topic thành một bảng key-value. 22/09/2026 · 6 phút đọc 9 Replication và ISR trong Kafka: cách không mất dữ liệu khi broker chết, và vì sao single-node không demo nổi Độ bền của Kafka đến từ replication — mỗi partition có nhiều bản sao trên nhiều broker, với ISR là tập bản sao đang theo kịp. Bài này đo thật trên lab single-node và dùng chính các giới hạn làm bằng chứng: RF=1 chỉ có một bản sao, thử RF=2 báo lỗi vì chỉ một broker, và một phát hiện trung thực về min.insync.replicas mà single-node không tái hiện nổi. Hiểu RF, ISR, min.insync.replicas và acks=all để cấu hình độ bền đúng trên cluster thật. 22/09/2026 · 7 phút đọc 10 Serialization và tiến hoá schema trong Kafka: vì sao Avro nhỏ hơn JSON 2,4 lần và không làm vỡ consumer Kafka chỉ chuyển byte — cách bạn mã hoá message quyết định băng thông, dung lượng và cả khả năng nâng cấp hệ thống. Bài này đo thật trong go-lab: cùng một bản ghi, JSON 88 byte, gob 115 byte, Avro chỉ 36 byte. Rồi chứng minh schema evolution bằng Avro resolution: thêm field có default đọc được dữ liệu cũ (channel lấy web), nhưng đổi kiểu double sang string bị từ chối ngay. Hiểu vì sao Schema Registry là bắt buộc khi nhiều team dùng chung topic. 22/09/2026 · 7 phút đọc

Còn 2 phần nữa sẽ lần lượt được đăng.