Kafka là distributed log: topic, partition và offset Cơ bản

Vấn đề

Service đơn hàng phát ba event cho một đơn: created, paid, shipped. Billing cần đọc để tính tiền, analytics cần đọc để làm báo cáo. Nếu coi Kafka như queue truyền thống (consumer lấy message ra là message biến mất), bạn sẽ không giải thích được:

• Vì sao hai service cùng đọc đủ ba event.
• Vì sao analytics đọc lại được từ đầu.
• Vì sao một consumer chậm có thể mất dữ liệu mà không ai xoá thủ công.

Mô hình đúng là distributed log: mỗi partition là một dãy record chỉ append, mỗi record có một offset. Đọc không xoá record. Broker dọn dữ liệu theo retention/compaction, không quan tâm consumer đã đọc hay chưa.

Tóm tắt nhanh

Khái niệm	Một câu
Topic	Tên luồng record, ví dụ orders
Partition	Một log có thứ tự; offset chỉ có nghĩa trong cặp (topic, partition)
Offset	Vị trí record trong partition, tăng dần, không dùng làm bộ đếm nghiệp vụ
Consumer group	Nhóm consumer chia partition; mỗi group giữ offset riêng
Retention	Thời gian/dung lượng giữ dữ liệu, độc lập với consumer
Replication	Mỗi partition có leader và follower trên các broker khác nhau (bài ISR)

Cấu trúc một topic

Đang tải diagram…

• Dữ liệu chia theo partition để scale ngang; mỗi partition được nhân bản sang broker khác.
• Thứ tự chỉ được bảo đảm trong một partition, không có thứ tự toàn topic. Cách chọn partition cho record: xem message key.
• Trong một group, mỗi partition tại một thời điểm chỉ thuộc một consumer (consumer group và rebalance).
• Group khác đọc độc lập, nên billing và analytics không ảnh hưởng nhau.

Luồng một record

Producer append; consumer đọc và commit vị trí riêng

Phóng to sơ đồ

Producer → Partition logorder-created

◀ Trước▶ PhátTiếp ▶↺ Từ đầuBước 1/4

Producer gửi record với key. Partitioner chọn partition; trong demo chỉ có một partition.

Sau ba lần append vào partition mới, log trông như sau:

Offset	Value
0	created
1	paid
2	shipped

Billing xử lý xong offset 2 thì commit 3 (offset sẽ đọc tiếp). Group analytics mới vẫn đọc lại từ offset 0 được, miễn là dữ liệu chưa bị retention dọn. Chi tiết commit nằm ở bài commit offset.

Retention: Kafka không chờ consumer

Với cleanup.policy=delete (mặc định), Kafka xoá cả segment cũ theo retention.ms (mặc định 7 ngày) hoặc retention.bytes (mặc định không giới hạn). Một consumer lag quá cửa sổ này sẽ không đọc lại được phần đã xoá. Chi tiết và compaction: retention và compaction.

Quy tắc thiết kế: cửa sổ retention phải lớn hơn thời gian sự cố tệ nhất mà bạn chấp nhận được trước khi consumer bắt kịp.

Kafka 4.x, KRaft và ghi chú về demo

Từ Kafka 4.0, ZooKeeper đã bị loại bỏ: Kafka chỉ chạy ở chế độ KRaft (metadata cluster do chính các controller của Kafka quản lý bằng Raft, không cần cụm ZooKeeper riêng). Cluster mới nên dựng ở KRaft; cluster cũ dùng ZooKeeper phải migrate trước khi nâng lên 4.0.

Demo trong repo chạy trên image Confluent Platform 7.6 (Kafka 3.6) với ZooKeeper, qua examples/docker-compose.yml. Offset, partition và consumer group hoạt động giống nhau giữa các phiên bản; chỉ phần dựng cluster khác. Các bài khác trong chuỗi mô tả cấu hình theo Kafka 4.x và sẽ ghi rõ khi một demo dùng phiên bản cũ.

Khi nào dùng / không dùng

Dùng Kafka log khi	Cân nhắc công cụ khác khi
Nhiều service cần đọc cùng event độc lập	Chỉ cần chia job cho worker, không cần replay (xem queue types RabbitMQ hoặc share groups)
Cần replay để dựng lại projection hoặc điều tra lỗi	Cần routing phức tạp theo pattern, priority queue
Throughput cao, ghi tuần tự	Volume rất nhỏ và không cần retention

Ví dụ thực tế

Billing dừng một giờ

Topic orders có 6 partition, retention 7 ngày (mặc định). Billing và analytics là hai group. Billing dừng một giờ để deploy: event vẫn nằm trong log, billing chạy lại từ offset đã commit.

Nếu billing ghi DB xong rồi crash trước khi commit offset, nó sẽ đọc lại event đó, nên ghi ledger theo unique eventId (idempotent consumer). Kafka chỉ quản lý log và offset, không biết side effect đã thành công hay chưa.

Chạy demo một broker (một partition, replication factor 1, chỉ để nhìn offset; không chứng minh chịu lỗi nhiều broker):

docker compose -f examples/docker-compose.yml up -d zookeeper kafka
npx --prefix examples ts-node examples/src/kafka-log/log-demo.ts

Script tạo topic mới, ghi created, paid, shipped, rồi một group mới đọc từ đầu và in partition, offset, key, value (partition 0, offset 0 đến 2). Log JSON của KafkaJS và TimeoutNegativeWarning xen vào output là nhiễu của client.

Trade-offs

Lợi ích của log

• Nhiều consumer group đọc cùng dữ liệu theo tốc độ riêng.
• Replay trong cửa sổ retention để dựng lại projection hoặc điều tra lỗi.
• Partition cho phép tăng throughput và giữ thứ tự theo key.

Trách nhiệm chuyển sang ứng dụng

• Thứ tự chỉ trong partition; key skew tạo partition nóng.
• Retention không chờ consumer chậm.
• Offset commit và side effect ngoài Kafka là hai việc riêng; cần idempotency hoặc outbox.

Checklist production

1. Đặt replication.factor=3 và min.insync.replicas=2 cho topic quan trọng (mặc định broker là RF=1, min ISR=1).
2. Chọn số partition theo throughput và số consumer song song tối đa, vì giảm partition không được.
3. Đặt retention theo SLA khôi phục, không để mặc định 7 ngày một cách vô thức.
4. Chọn key theo entity cần thứ tự.
5. Theo dõi consumer lag theo từng partition và theo thời gian.
6. Cluster mới dùng KRaft; không lên kế hoạch dựa vào ZooKeeper.

Sai lầm thường gặp

Sai lầm thường gặp

“Consumer đọc xong là Kafka xoá message.” Kafka giữ theo retention/compaction. Group khác vẫn đọc được cùng record nếu còn trong log.

Sai lầm thường gặp

“Offset 10 là record thứ 10 của cả topic.” Offset gắn với partition. Khi debug, luôn log đủ topic, partition, offset.

Sai lầm thường gặp

“Commit offset là xác nhận thanh toán xong.” Kafka chỉ biết vị trí đọc. Side effect cần bằng chứng thành công riêng và idempotency.

Tóm tắt

Tóm tắt

• Topic chia thành partition; mỗi partition là log có offset và thứ tự riêng.
• Đọc không xoá; mỗi consumer group có vị trí đọc độc lập.
• Retention/compaction quyết định dữ liệu còn để replay, không phụ thuộc consumer.
• Kafka 4.0 bỏ ZooKeeper, chỉ còn KRaft.

Tự kiểm tra: (1) Billing commit offset 3, analytics group mới có đọc lại offset 0 được không, điều kiện gì cần đúng? (2) Vì sao cùng key giúp thứ tự nhưng không bảo đảm thứ tự mọi event trong topic? (3) DB đã ghi nhưng offset chưa commit rồi consumer crash: chuyện gì xảy ra khi restart?

Tham khảo

• Design — Apache Kafka 4.2
• Topic Configurations — Apache Kafka 4.2
• Upgrade notes — Apache Kafka 4.2