Kafka Thực Chiến on Thanh HV's Blog

Bài 11 (Nâng cao) — Cơ chế lưu trữ: vì sao Kafka nhanh

Mon, 25 May 2026 08:00:00 +0700

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 độ.

Bài 10 — Kiến trúc thực chiến

Sat, 23 May 2026 08:00:00 +0700

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.

Bài 9 — Performance Tuning

Wed, 20 May 2026 08:00:00 +0700

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.

Bài 8 — Schema Registry & Schema Evolution

Sun, 17 May 2026 08:00:00 +0700

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:

Bài 7 — Retry, Backoff & Dead Letter Queue

Thu, 14 May 2026 08:00:00 +0700

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:

Bài 6 — Idempotent Producer & Transactions (Exactly-Once)

Tue, 12 May 2026 08:00:00 +0700

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.

Bài 5 — Replication, acks & ISR

Sun, 10 May 2026 08:00:00 +0700

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 4 — Offset & Delivery Semantics

Fri, 08 May 2026 08:00:00 +0700

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”.

Bài 3 — Partitioning & Đảm bảo thứ tự

Wed, 06 May 2026 08:00:00 +0700

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!

Bài 2 — Consumer Group & Rebalance

Sun, 03 May 2026 08:00:00 +0700

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.

Bài 1 — Topic, Partition, Producer & Consumer

Fri, 01 May 2026 08:00:00 +0700

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, …).