Skip to content

Apache Kafka Fundamentals: Topics, Partitions, Replication và Delivery Semantics

19 min read
On this page

Apache Kafka là một distributed event streaming platform dùng để publish, store, process và consume event streams. Kafka thường được dùng trong hệ thống microservices, event-driven architecture, log aggregation, data pipelines và real-time processing.

1. Tóm tắt nhanh#

Khái niệm Tóm tắt
Broker Một Kafka server lưu trữ và phục vụ dữ liệu
Cluster Tập hợp nhiều broker hoạt động cùng nhau
Topic Luồng logic chứa các record/event cùng loại
Partition Phân đoạn có thứ tự của topic; đơn vị chính để phân phối dữ liệu và song song hóa
Offset Vị trí tuần tự của record trong một partition
Producer Ứng dụng ghi record vào Kafka
Consumer Ứng dụng đọc record từ Kafka
Consumer group Nhóm consumer cùng chia sẻ việc đọc topic
Replication Sao chép partition để tăng khả năng chịu lỗi
ISR In-Sync Replicas, các replica đang đồng bộ đủ tốt với leader
Retention Chính sách xác định Kafka giữ record trong bao lâu hoặc đến khi đạt giới hạn dung lượng
At-most-once Có thể mất record, nhưng tránh xử lý lặp theo semantics của consumer
At-least-once Không bỏ qua record đã được xác nhận theo semantics, nhưng có thể xử lý trùng
Exactly-once Bảo đảm xử lý/ghi kết quả đúng một lần trong phạm vi được Kafka hỗ trợ; không tự động bao phủ mọi side effect bên ngoài

Sơ đồ tổng quan#

flowchart LR
    P1[Producer A] --> T
    P2[Producer B] --> T
    subgraph K[Kafka Cluster]
      T[Topic: orders]
      T --> PA[Partition 0]
      T --> PB[Partition 1]
      T --> PC[Partition 2]
      PA -. replication .-> RA[Replica]
      PB -. replication .-> RB[Replica]
      PC -. replication .-> RC[Replica]
    end
    PA --> C1[Consumer group<br/>member 1]
    PB --> C2[Consumer group<br/>member 2]
    PC --> C3[Consumer group<br/>member 3]

Cốt lõi: topic là luồng logic; partition tạo thứ tự cục bộ và khả năng song song; replication tăng khả năng chịu lỗi; consumer group phân chia công việc đọc.

2. Kafka là gì và dùng để làm gì?#

Kafka là một nền tảng event streaming phân tán. Ứng dụng có thể ghi event vào Kafka, lưu trữ chúng theo cấu hình retention, rồi cho một hoặc nhiều ứng dụng khác đọc độc lập.

Ví dụ trong hệ thống thương mại điện tử:

Order Service
     |
     | OrderCreated
     v
 Kafka topic: orders
     |
     +----> Payment Service
     |
     +----> Inventory Service
     |
     +----> Notification Service
     |
     +----> Analytics pipeline

Khi có đơn hàng mới, Order Service phát event OrderCreated. Các service khác tiêu thụ event để xử lý nghiệp vụ riêng. Producer không cần gọi trực tiếp từng consumer, giúp giảm coupling và hỗ trợ mở rộng.

Kafka phù hợp với: - Event-driven architecture và giao tiếp bất đồng bộ. - Thu thập log, metrics và event. - Streaming dữ liệu giữa các hệ thống. - Xây dựng pipeline phân tích gần thời gian thực. - Phát lại dữ liệu để tái xử lý khi cần, trong giới hạn retention.

Kafka không tự thay thế mọi loại message broker, database hay workflow engine. Việc chọn công nghệ cần dựa trên yêu cầu ordering, retention, routing, transaction và operational complexity.

3. Kiến trúc cơ bản: Broker và Cluster#

3.1. Broker#

Broker là một Kafka server. Broker nhận record từ producer, lưu partition log trên đĩa, phục vụ consumer fetch dữ liệu và tham gia replication.

Một cluster có thể có nhiều broker:

flowchart TB
    P[Producers] --> K[Kafka Cluster]
    C[Consumers] --> K
    subgraph K[Kafka Cluster]
      B1[Broker 1]
      B2[Broker 2]
      B3[Broker 3]
    end

Mỗi partition có một replica leader tại một broker và có thể có các follower replicas trên broker khác. Producer và consumer thông thường tương tác với leader của partition; follower phục vụ replication và có thể được dùng trong một số cơ chế đọc được cấu hình.

3.2. Cluster controller và metadata#

Kafka cần phối hợp metadata như broker, topic, partition và leader. Các phiên bản Kafka hiện đại sử dụng KRaft để quản lý metadata bằng quorum controller, thay cho kiến trúc ZooKeeper cũ.

Trong hệ thống mới, nên hiểu KRaft là mô hình quản lý metadata hiện hành; ZooKeeper chủ yếu còn gặp trong các cluster cũ hoặc tài liệu lịch sử.

4. Topic: luồng dữ liệu logic#

Topic là tên logic của một luồng record. Ví dụ:

  • orders
  • payments
  • user-events
  • inventory-updates

Producer ghi record vào topic; consumer subscribe topic để đọc. Topic không nhất thiết tương ứng với một bảng database hay một queue duy nhất.

Ví dụ record JSON:

{
  "eventId": "evt-10001",
  "eventType": "OrderCreated",
  "orderId": "ord-9001",
  "customerId": "cus-42",
  "total": 1250000,
  "currency": "VND",
  "createdAt": "2026-09-28T10:30:00Z"
}

Record Kafka thường có: - Key: tùy chọn, dùng trong partitioning và có thể hỗ trợ xử lý theo entity. - Value: payload của event. - Timestamp: thời điểm gắn với record theo cấu hình producer/broker. - Headers: metadata bổ sung dạng key-value. - Offset: vị trí của record trong partition, do Kafka quản lý.

Topic không phải queue truyền thống#

Một queue truyền thống thường được hình dung là message được lấy khỏi hàng đợi sau khi consume. Kafka giữ record theo retention policy, và consumer theo dõi offset của riêng mình. Nhiều consumer group có thể đọc cùng một topic độc lập.

5. Partition: nền tảng ordering và scalability#

Một topic được chia thành một hoặc nhiều partition. Mỗi partition là một log append-only có thứ tự.

Ví dụ topic orders có 3 partition:

Topic: orders

Partition 0:  offset 0 -> 1 -> 2 -> 3 -> ...
Partition 1:  offset 0 -> 1 -> 2 -> 3 -> ...
Partition 2:  offset 0 -> 1 -> 2 -> 3 -> ...

Ordering được đảm bảo bên trong một partition, không có thứ tự tổng thể tự nhiên giữa các partition khác nhau.

5.1. Vì sao cần partition?#

  1. Parallelism: nhiều consumer trong cùng group có thể xử lý các partition khác nhau đồng thời.
  2. Scalability: partition có thể phân bố trên nhiều broker, tăng khả năng lưu trữ và throughput.
  3. Ordering theo key: record cùng key thường được gửi đến cùng partition, giúp giữ thứ tự của một entity trong điều kiện cấu hình partitioning không thay đổi.

5.2. Key quyết định partition ra sao?#

Producer có thể chỉ định partition trực tiếp hoặc cung cấp key. Với partitioner mặc định phổ biến, record có key được phân phối dựa trên hash của key; record không key có thể được phân phối theo chiến lược cân bằng tải.

Ví dụ:

key = order-100  -> Partition 1
key = order-101  -> Partition 0
key = order-102  -> Partition 2
key = order-100  -> Partition 1

Nhờ đó, event của cùng một đơn hàng có thể được xử lý theo thứ tự trong cùng partition.

Lưu ý: tăng số partition có thể làm thay đổi mapping key-to-partition đối với một số partitioner, vì vậy cần cân nhắc nếu hệ thống phụ thuộc chặt vào ordering theo key.

5.3. Partition count và consumer parallelism#

Trong một consumer group, tại một thời điểm, mỗi partition được gán cho tối đa một consumer member trong group. Một consumer có thể được gán nhiều partition.

Ví dụ:

Topic: orders (4 partitions)
Consumer group: order-processors

Consumer A <- Partition 0, 1
Consumer B <- Partition 2
Consumer C <- Partition 3
Consumer D <- (idle)

Với 4 partition, group có thể có tối đa 4 consumer member đang đọc partition này song song. Thêm consumer vượt quá số partition không tự tăng parallelism cho topic đó.

6. Offset: vị trí đọc trong partition#

Offset là số thứ tự của record trong một partition. Offset chỉ có ý nghĩa trong phạm vi partition đó; offset 12 của partition 0 không có quan hệ thứ tự với offset 12 của partition 1.

Partition 0:
offset 0 | OrderCreated
offset 1 | OrderUpdated
offset 2 | OrderPaid
offset 3 | OrderShipped

Consumer theo dõi vị trí đọc bằng offset. Khi consumer group commit offset, Kafka lưu tiến độ để group có thể tiếp tục sau khi consumer restart hoặc partition được gán lại.

Auto commit và manual commit#

  • Auto commit: Kafka client tự commit offset theo cấu hình. Dễ triển khai nhưng cần hiểu mối quan hệ giữa thời điểm commit và thời điểm xử lý record.
  • Manual commit: ứng dụng chủ động commit khi đã hoàn thành một mốc xử lý. Linh hoạt hơn, nhưng cần xử lý lỗi, retry và rebalance cẩn thận.

Nếu commit offset trước khi xử lý xong rồi ứng dụng bị crash, record có thể không được xử lý lại. Nếu xử lý xong nhưng crash trước khi commit, record có thể được đọc lại.

Đó là một nguyên nhân phổ biến dẫn đến at-most-once hoặc at-least-once behavior.

7. Producer: ghi event vào Kafka#

Producer là client gửi record đến topic. Producer có thể cấu hình: - bootstrap.servers: broker dùng để khởi đầu kết nối và khám phá metadata. - key.serializer, value.serializer: serialize key/value. - acks: mức xác nhận ghi. - enable.idempotence: hỗ trợ tránh duplicate do retry ở producer trong phạm vi Kafka protocol. - retries, delivery.timeout.ms, request.timeout.ms: hành vi retry và timeout.

Ví dụ Java với Kafka Producer API:

Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,
          StringSerializer.class.getName());
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,
          StringSerializer.class.getName());
props.put(ProducerConfig.ACKS_CONFIG, "all");
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true");

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

ProducerRecord<String, String> record =
    new ProducerRecord<>("orders", "order-100", "{\"type\":\"OrderCreated\"}");

producer.send(record, (metadata, exception) -> {
    if (exception != null) {
        exception.printStackTrace();
    } else {
        System.out.printf("topic=%s partition=%d offset=%d%n",
                metadata.topic(), metadata.partition(), metadata.offset());
    }
});

producer.flush();
producer.close();

Đây là ví dụ minh họa API; trong ứng dụng thực tế nên quản lý producer theo vòng đời ứng dụng, tránh tạo/đóng producer cho từng record.

acks nghĩa là gì?#

Giá trị Ý nghĩa khái quát

acks=0 Producer không chờ broker xác nhận

acks=1 Leader xác nhận đã ghi record

acks=all Leader chờ các replica thuộc ISR xác nhận theo điều kiện replication#

acks=all thường được chọn khi cần độ bền dữ liệu cao hơn, nhưng độ bền thực tế còn phụ thuộc replication.factor, min.insync.replicas, trạng thái ISR và cấu hình cluster.

Producer idempotence#

Idempotent producer giúp Kafka loại bỏ duplicate phát sinh từ một số tình huống retry của producer, dựa trên producer ID và sequence number. Nó không tự động làm cho mọi thao tác nghiệp vụ ở database, API hay hệ thống bên ngoài trở nên exactly-once.

8. Replication: chịu lỗi và tính sẵn sàng#

Kafka có thể lưu nhiều replica của một partition trên các broker khác nhau.

Ví dụ replication factor = 3:

flowchart LR
    P[Producer] --> L
    subgraph R[Partition replicas]
      L[Broker 1<br/>Leader]
      F1[Broker 2<br/>Follower]
      F2[Broker 3<br/>Follower]
    end
    L -. replication .-> F1
    L -. replication .-> F2
    C[Consumer] --> L
  • Leader replica: xử lý đọc/ghi thông thường của partition.
  • Follower replica: fetch dữ liệu từ leader để duy trì bản sao.
  • ISR: tập replica đang đồng bộ với leader theo tiêu chí Kafka.

Nếu leader broker gặp sự cố, Kafka có thể bầu một replica phù hợp trong ISR làm leader mới, tùy cấu hình và trạng thái cluster.

Replication factor và min.insync.replicas#

  • replication.factor: số bản sao được cấu hình cho mỗi partition.
  • min.insync.replicas: số replica tối thiểu cần có trong ISR để một write với acks=all được chấp nhận.

Ví dụ replication factor 3 và min.insync.replicas=2: khi ISR còn ít nhất 2 replica, write acks=all có thể được chấp nhận. Nếu ISR giảm dưới ngưỡng, producer có thể nhận lỗi thay vì Kafka chấp nhận một write có độ bền thấp hơn cấu hình mong muốn.

Quan trọng: replication không thay thế backup, và không bảo vệ khỏi mọi dạng lỗi logic, xóa nhầm, corruption hoặc lỗi cấu hình đồng bộ lan rộng.

9. Consumer và Consumer Group#

Consumer đọc record từ Kafka. Consumer group cho phép nhiều consumer instance phối hợp xử lý một topic.

flowchart TD
    T[Topic: orders] --> P0[Partition 0]
    T --> P1[Partition 1]
    T --> P2[Partition 2]
    P0 --> C1[Consumer A]
    P1 --> C2[Consumer B]
    P2 --> C3[Consumer C]
    subgraph G[Consumer group: order-service]
      C1
      C2
      C3
    end

Consumer group có ý nghĩa gì?#

  • Các member trong cùng group chia nhau partition.
  • Mỗi partition được gán cho tối đa một member trong group tại một thời điểm.
  • Hai group khác nhau có thể đọc cùng topic độc lập, mỗi group có offset riêng.
  • Khi member tham gia/rời group hoặc partition thay đổi, Kafka có thể thực hiện rebalance để phân công lại.

Ví dụ: - Group payment-service đọc orders để xử lý thanh toán. - Group analytics-service đọc cùng topic để cập nhật báo cáo. - Hai group không lấy mất message của nhau; mỗi group duy trì tiến độ đọc riêng.

Rebalance#

Rebalance là quá trình phân phối lại partition assignment trong consumer group. Nó có thể xảy ra khi consumer join/leave, heartbeat timeout, subscription thay đổi hoặc metadata topic thay đổi.

Trong lúc rebalance, việc xử lý có thể tạm gián đoạn. Ứng dụng cần commit offset đúng thời điểm, xử lý idempotently và cấu hình consumer phù hợp để giảm rebalance không cần thiết.

10. Delivery semantics: At-most-once, At-least-once, Exactly-once#

Đây là phần quan trọng khi thiết kế consumer và xử lý event.

10.1. At-most-once#

Ý tưởng: mỗi record được xử lý không quá một lần theo flow của consumer; đổi lại, record có thể bị mất khỏi tiến trình xử lý nếu commit offset trước khi xử lý thành công.

sequenceDiagram
    participant C as Consumer
    participant K as Kafka
    participant S as Processing

    C->>K: Poll record at offset N
    C->>K: Commit offset N+1
    C->>S: Process record N
    S--xC: Crash before completion
    Note over C,S: Sau restart, consumer tiếp tục từ N+1.<br/>Record N có thể không được xử lý lại.

Phù hợp khi: mất một số record có thể chấp nhận được, hoặc dữ liệu có thể được tái tạo từ nguồn khác và ưu tiên tránh xử lý lặp.

10.2. At-least-once#

Ý tưởng: chỉ commit offset sau khi xử lý thành công. Nếu consumer xử lý xong nhưng crash trước khi commit, record có thể được đọc và xử lý lại.

sequenceDiagram
    participant C as Consumer
    participant K as Kafka
    participant S as Processing

    C->>K: Poll record at offset N
    C->>S: Process record N
    S-->>C: Processing succeeded
    C--xK: Commit offset fails / consumer crashes
    Note over C,K: Sau restart, offset N có thể được đọc lại.
    C->>K: Poll record N again
    C->>S: Process record N again

At-least-once tránh bỏ qua record do commit quá sớm, nhưng có thể tạo duplicate processing. Vì vậy, handler nên được thiết kế idempotent hoặc có cơ chế deduplication.

Ví dụ idempotency theo eventId:

CREATE TABLE processed_events (
    event_id VARCHAR(100) PRIMARY KEY,
    processed_at TIMESTAMP NOT NULL
);

Trong cùng transaction database: 1. Thử insert eventId vào processed_events. 2. Nếu insert thành công, áp dụng thay đổi nghiệp vụ. 3. Nếu eventId đã tồn tại, bỏ qua xử lý lặp. 4. Commit transaction.

Việc ghi dấu đã xử lý và cập nhật dữ liệu nghiệp vụ phải được bảo vệ bởi cùng transaction nếu dùng chung database; nếu tách rời, cần thiết kế nhất quán khác.

10.3. Exactly-once#

Ý tưởng: tránh tác động trùng trong phạm vi một pipeline được hỗ trợ. Kafka cung cấp transactional producer và cơ chế đọc/ghi transactionally để hỗ trợ exactly-once processing giữa Kafka topics.

Một pipeline Kafka-to-Kafka có thể: 1. Đọc record từ input topic. 2. Xử lý record. 3. Ghi kết quả vào output topic trong transaction. 4. Commit output records và consumer offsets như một transaction.

Consumer downstream thường cần cấu hình isolation.level=read_committed để chỉ đọc record thuộc transaction đã commit.

flowchart LR
    A[Input topic] --> B[Transactional processor]
    B --> C[Begin transaction]
    C --> D[Write output records]
    D --> E[Commit input offsets in transaction]
    E --> F[Commit transaction]
    F --> G[Output topic: committed records]

Giới hạn quan trọng: exactly-once của Kafka không tự động bảo đảm một side effect bên ngoài Kafka, ví dụ gửi email, gọi payment API hoặc ghi vào database độc lập, chỉ xảy ra đúng một lần. Với external systems, thường cần idempotency key, transaction integration, inbox/outbox pattern hoặc cơ chế phối hợp phù hợp.

So sánh ba semantics#

Semantics Commit thường Nguy cơ mất Nguy cơ xử lý được thực hiện record trùng

At-most-once Trước khi xử lý Có, nếu crash sau Thấp trong flow commit trước xử này lý

At-least-once Sau khi xử lý Thấp hơn, nếu Có thành công offset được quản
lý đúng

Exactly-once Transactional Tránh mất/ghi Tránh duplicate coordination lệch trong phạm effect trong phạm trong phạm vi hỗ vi transaction vi được bảo đảm trợ#

Tên gọi semantics không thay thế thiết kế hệ thống. Cần xác định rõ ranh giới: producer-to-Kafka, Kafka-to-Kafka, hay Kafka-to-database/API.

11. Retention, log compaction và replay#

Kafka lưu record theo partition log và áp dụng chính sách lưu trữ.

11.1. Retention#

Retention có thể dựa trên thời gian hoặc dung lượng. Record có thể bị xóa khỏi log theo chính sách retention ngay cả khi một consumer group chưa đọc đến, vì vậy cần cấu hình thời gian lưu phù hợp với nhu cầu replay và vận hành.

11.2. Log compaction#

Với topic cấu hình cleanup.policy=compact, Kafka giữ lại giá trị mới nhất theo key trong quá trình compaction, thay vì chỉ dựa vào tuổi record để xóa. Compaction diễn ra nền và không có nghĩa là mọi bản ghi cũ biến mất ngay lập tức.

Thường dùng cho: - Topic lưu trạng thái mới nhất của entity theo key. - Changelog hoặc dữ liệu cần khôi phục trạng thái. - Một số luồng đồng bộ cấu hình.

11.3. Replay#

Consumer group có thể reset offset hoặc dùng group mới để đọc lại dữ liệu còn trong retention. Replay hữu ích khi: - Xây dựng lại projection/read model. - Khắc phục lỗi xử lý. - Tạo một consumer mới cho use case mới.

Replay có thể tái thực hiện side effect. Trước khi chạy, cần đánh giá idempotency, khả năng chịu tải downstream và phạm vi offset cần đọc lại.

12. Ordering: Kafka bảo đảm thứ tự đến đâu?#

Kafka bảo đảm thứ tự record trong một partition. Kafka không cung cấp thứ tự tổng thể giữa nhiều partition của cùng topic.

Nếu nghiệp vụ yêu cầu thứ tự theo orderId, hãy dùng orderId làm key để các event của cùng đơn hàng thường đi vào cùng partition. Consumer cũng cần xử lý tuần tự trong partition hoặc có cơ chế bảo toàn thứ tự tương ứng.

Các yếu tố có thể ảnh hưởng ordering: - Nhiều producer gửi đồng thời. - Retry và cấu hình producer. - Thay đổi số partition hoặc partitioner. - Consumer xử lý bất đồng bộ song song bên trong cùng partition. - Rebalance và logic commit offset.

Vì vậy, “Kafka có ordering” cần được diễn đạt chính xác: ordering theo partition, không phải toàn cluster hoặc toàn topic.

13. Kafka với database và transactional outbox#

Một vấn đề phổ biến là service vừa ghi database vừa publish event:

1. INSERT order vào database
2. Publish OrderCreated lên Kafka

Nếu database commit thành công nhưng publish Kafka thất bại, hệ thống có thể có order mà không có event. Đảo thứ tự hai thao tác cũng tạo rủi ro ngược lại.

Transactional outbox là một pattern thường dùng: 1. Trong một transaction database, ghi dữ liệu nghiệp vụ và một bản ghi outbox. 2. Một publisher/CDC process đọc outbox và phát event lên Kafka. 3. Đánh dấu hoặc quản lý trạng thái phát event; consumer vẫn nên idempotent vì publish có thể lặp.

flowchart TD
    A[Order Service] --> B[DB transaction]
    B --> C[Update orders table]
    B --> D[Insert outbox event]
    D --> E[Outbox relay / CDC]
    E --> F[Kafka topic: orders]
    F --> G[Consumers]

Outbox giúp tránh khoảng trống nguyên tử giữa database transaction và publish event, nhưng cần xử lý retry, duplicate publication, ordering, outbox cleanup và monitoring.

14. Các cấu hình và thực hành cần biết#

Mục Ý nghĩa / gợi ý

bootstrap.servers Danh sách broker bootstrap để client lấy metadata

group.id Định danh consumer group

auto.offset.reset Hành vi khi group chưa có offset hợp lệ; ví dụ earliest hoặc latest

enable.auto.commit Bật/tắt tự động commit offset

acks Mức xác nhận producer chờ

enable.idempotence Bật producer idempotence

replication.factor Số replica của partition

min.insync.replicas Ngưỡng ISR cho write acks=all

retention.ms Thời gian retention theo cấu hình topic/broker

cleanup.policy Chính sách cleanup, thường delete hoặc compact#

Thực hành tốt: - Chọn key theo entity cần ordering và partition distribution. - Thiết kế consumer idempotent, đặc biệt với at-least-once. - Commit offset sau khi xử lý thành công nếu cần at-least-once. - Theo dõi consumer lag, under-replicated partitions, ISR và lỗi producer. - Đặt replication và min.insync.replicas dựa trên yêu cầu durability và availability. - Dùng schema có quản lý version khi event được nhiều service chia sẻ. - Tránh đưa dữ liệu nhạy cảm vào event nếu không cần thiết; áp dụng kiểm soát truy cập và retention phù hợp. - Kiểm thử retry, rebalance, broker failure và replay trước khi production.

15. Những nhầm lẫn thường gặp#

  1. Topic là queue: Kafka giữ log theo retention; nhiều consumer group có thể đọc độc lập.
  2. Partition có thứ tự toàn cục: thứ tự chỉ được bảo đảm trong từng partition.
  3. Nhiều consumer hơn partition luôn tăng throughput: trong cùng group, consumer dư có thể không được gán partition.
  4. Offset là ID toàn topic: offset thuộc từng partition.
  5. acks=all nghĩa là mọi replica đều xác nhận: nó liên quan đến ISR và cấu hình replication, không đồng nghĩa tất cả replica được cấu hình đều phải phản hồi.
  6. Replication là backup: replication hỗ trợ chịu lỗi broker, không thay thế backup/khôi phục trước lỗi logic.
  7. At-least-once không có duplicate: record có thể được xử lý lại nếu crash xảy ra trước commit offset.
  8. Idempotent producer = exactly-once toàn hệ thống: producer idempotence xử lý một số duplicate do retry ở Kafka; không bảo đảm side effect bên ngoài.
  9. Exactly-once Kafka bao phủ email/API/database: chỉ bảo đảm trong ranh giới và cơ chế được hỗ trợ; external side effect cần thiết kế riêng.
  10. Consumer nhận message là message bị xóa: consumer đọc theo offset; record vẫn được giữ theo retention/compaction policy.

16. Câu hỏi phỏng vấn Kafka Fundamentals#

Q1. Kafka là gì?#

Một distributed event streaming platform cho phép publish, store, process và consume event streams với khả năng mở rộng và chịu lỗi.

Q2. Topic và partition khác nhau thế nào?#

Topic là luồng logic; partition là log có thứ tự bên trong topic, đồng thời là đơn vị phân phối và song song hóa.

Q3. Offset là gì?#

Vị trí của record trong một partition. Consumer group dùng offset để lưu tiến độ đọc.

Q4. Consumer group dùng để làm gì?#

Cho phép nhiều consumer cùng chia việc đọc topic. Các group khác nhau có tiến độ độc lập.

Q5. Kafka bảo đảm ordering không?#

Có, trong từng partition. Không có thứ tự tổng thể giữa các partition.

Q6. Replication factor = 3 nghĩa là gì?#

Mỗi partition có ba replica theo cấu hình, thường gồm một leader và hai follower; các replica cần được phân bố phù hợp trên broker để hỗ trợ chịu lỗi.

Q7. ISR là gì?#

In-Sync Replicas: các replica đang đồng bộ với leader theo tiêu chí Kafka, có vai trò trong replication và lựa chọn leader.

Q8. acks=all và min.insync.replicas phối hợp ra sao?#

Với acks=all, leader chờ các replica trong ISR theo giao thức; min.insync.replicas đặt ngưỡng ISR tối thiểu để chấp nhận write.

Q9. At-most-once và at-least-once khác nhau thế nào?#

At-most-once có thể mất record nếu commit trước khi xử lý; at-least-once xử lý trước rồi commit nên có thể xử lý trùng khi crash.

Q10. Làm sao xử lý duplicate event?#

Dùng idempotent handler, event ID duy nhất, deduplication hoặc transaction database phù hợp; không chỉ dựa vào producer idempotence.

Q11. Exactly-once trong Kafka có nghĩa gì?#

Kafka hỗ trợ transactional processing để phối hợp đọc/ghi và commit offset trong một transaction trong các pipeline được hỗ trợ. Nó không tự bao phủ side effect bên ngoài Kafka.

Q12. Khi nào dùng key?#

Khi cần phân phối record theo entity, giữ ordering cục bộ theo key hoặc kiểm soát partition placement.

Q13. Retention và compaction khác nhau thế nào?#

Retention theo thời gian/dung lượng có thể loại bỏ record cũ; compaction giữ lại trạng thái mới nhất theo key trong quá trình cleanup.

Q14. Consumer lag là gì?#

Khoảng cách giữa vị trí record mới nhất của partition và tiến độ commit/đọc của consumer group, thường dùng để theo dõi mức tụt hậu xử lý.

17. Kết luận#

Hãy ghi nhớ Kafka qua chuỗi khái niệm:

Producer → Topic → Partition → Broker/Replication → Consumer Group → Offset → Delivery Semantics.

  • Topic tổ chức luồng event.
  • Partition quyết định thứ tự cục bộ và mức song song.
  • Replication/ISR hỗ trợ độ sẵn sàng và durability.
  • Consumer group/offset quản lý cách đọc và tiến độ.
  • At-least-once thường đi cùng idempotent consumer.
  • Exactly-once cần xác định rõ ranh giới bảo đảm, đặc biệt khi có database hoặc API bên ngoài.

Khi thiết kế Kafka cho production, không chỉ chọn cấu hình throughput; cần đồng thời xác định ordering, durability, replay, duplicate handling, schema evolution, observability và cách khôi phục khi có lỗi.