Apache Kafka

August 26, 2025

Kafka Overall

1. Kafka Topics

  • Có nhiều topics, mỗi topic được xác định bởi chính tên (duy nhất), mỗi topic có nhiều partitions (10 hay 100 partitions)
  • Topics và partitions có thể có nhiều replica
  • Clusters > Brokers > Topics & partitions
  • Topic giống như table trong database
  • The sequence of messages is called a data stream (chính vì thế nên Kafka mới được gọi là Data stream platform)
  • Data is kept only for a limited time (default is one week - configurable)
  • Kafka Producers to send data

Kafka Producer

  • Kafka Consumers to read the data

2. Kafka Messages

  • value
  • key - value

Kafka Message

Cách message serializer

Kafka Message serializer

3. Zookeeper

  • Zookeeper manages brokers (keeps a list of them)
  • Zookeeper sends notifications to Kafka in case of changes (e.g. new topic, broker dies, broker comes up, delete topics, etc..)
  • Kafka 2.x can't work without Zookeeper
  • Kafka 3.x can work without Zookeeper (KIP 500 - using Kafka Raft instead)
  • Kafka 4.x will not have Zookeeper
  • Zookeeper helps in performing leader election of partitions
  • Zookeeper has a leader (Writes) the rest of the servers are followers (reads)

Kafka Raft sinh ra để thay thế Zookeeper, nếu dùng Kafka 4.x thì nên dùng Kafka Raft theo kiến kiến của Kafka.

4. Setup Kafka

Để setup Kafka thì dùng Docker, vài notes khi setup.

  • default port 9092, in case want to change port in server.properties
# example for port 9093
listeners=PLAINTEXT://:9093

5. Producer Acknowledgement

5.1. Producer: acks = 0

Producer acks = 0 Giống như trong hình chỉ có 1 chiều

  • Producer gửi thông điệp mà không chờ xác nhận từ Broker. Điều này có nghĩa là Producer sẽ coi thông điệp là "đã gửi thành công" ngay sau khi gửi, bất kể Broker có nhận được hay không.
  • Đây là chế độ "fire-and-forget" (gửi và quên), ưu tiên tốc độ và hiệu suất cao nhất, nhưng hy sinh độ tin cậy.

Tình huống sử dụng

Dữ liệu không quan trọng (non-critical data):

  • Khi mất một vài thông điệp không ảnh hưởng nghiêm trọng đến hệ thống, ví dụ: dữ liệu log, số liệu thống kê không quan trọng, hoặc dữ liệu có thể được tái tạo lại.
  • Ví dụ: Các ứng dụng ghi log hiệu suất hoặc thu thập dữ liệu telemetry, nơi mất một số bản ghi không gây ra vấn đề lớn.

Ưu tiên hiệu suất tối đa

  • Trong các hệ thống yêu cầu throughput cao và độ trễ thấp (low latency), như xử lý dữ liệu thời gian thực với khối lượng lớn.
  • Vì không chờ xác nhận, Producer có thể gửi thông điệp liên tục mà không bị chậm trễ bởi phản hồi từ Broker.

Dữ liệu có thể được tái tạo hoặc không cần đảm bảo thứ tự

Rủi ro khi sử dụng

  • Mất dữ liệu: Nếu Broker không nhận được thông điệp (do lỗi mạng, Broker sập, v.v.), Producer không biết và sẽ không thử gửi lại.
  • Không đảm bảo thứ tự: Vì không có xác nhận, Producer không thể biết liệu thông điệp có được ghi đúng thứ tự vào partition hay không.
  • Không phù hợp với hệ thống yêu cầu độ tin cậy cao: Nếu ứng dụng yêu cầu đảm bảo rằng mọi thông điệp đều được ghi vào Kafka, acks=0 không phải là lựa chọn phù hợp.

5.2. Producer: acks = 1

Producer acks = 1

  • Producer chờ Leader Broker xác nhận đã nhận thông điệp. Đảm bảo tốt hơn nhưng vẫn có nguy cơ mất dữ liệu nếu Leader thất bại trước khi sao chép sang Follower.

5.3. Producer: acks = all

Producer acks = all

  • Producer chờ tất cả các replica (ISR - In-Sync Replicas) xác nhận. Đảm bảo độ tin cậy cao nhất nhưng làm tăng độ trễ.

Tình huống sử dụng

  • Khi cần độ tin cậy cao (high durability) và đảm bảo rằng thông điệp không bị mất ngay cả khi Leader Broker gặp sự cố.
  • Phù hợp với các ứng dụng như: giao dịch tài chính, đơn hàng thương mại điện tử, hoặc hệ thống yêu cầu dữ liệu không được phép mất.

min.insync.replicas

  • min.insync.replicas là một cấu hình ở mức topic hoặc mức Broker, quy định số lượng replica tối thiểu trong ISR phải xác nhận việc ghi thông điệp để được coi là thành công khi sử dụng acks=all.
  • Nếu số lượng replica trong ISR nhỏ hơn giá trị min.insync.replicas, Producer sẽ nhận được lỗi NotEnoughReplicasException và thông điệp sẽ không được ghi.
  • Điều này giúp đảm bảo rằng thông điệp được sao chép đủ số lượng replica để duy trì độ tin cậy ngay cả trong trường hợp một số Broker gặp sự cố.
  • Căn bằng giữa độ tin cậy và tính sẵn sàng, thông thường, đặt min.insync.replicas nhỏ hơn replication.factor (ví dụ: replication.factor=4, min.insync.replicas=2) để cân bằng giữa độ tin cậy và tính sẵn sàng.

Producer Idempotent

Producer idempotence

  • Nhằm đảm bảo tránh duplicated messages khi retry, lý tưởng nhất khi dùng chung producer acks = all
  • Default turn on since Kafka 3.0, nếu muốn set bằng tay thì:
producerProps.put("enable.idempotence", true);

Producer/Topic Messaage Conpression (Nén messages)

  • Rất ít khi dùng với Microservices, message đạng json là đủ. Dùng trong trường hợp khối lượng dữ liệu lớn (log, sự kiện IoT, dữ liệu phân tích) nén giúp giảm kích thước thông điệp, từ đó giảm tải cho mạng và lưu trữ trên Broker.
  • conpression.type của producer hoặc topic
    • Gzip: tỷ lệ nén cao, sử dụng nhiều CPU nên thời gian nén/giải nén lâu, thường dc dùng Log, dữ liệu văn bản lớn (Json, XML), không yêu cầu giản nén tức thời.
    • Snappy: tỷ lệ nén trung bình nên tốc độ nén/giải nén nhanh hơn Gzip
    • LZ4: Tốc độ nén/giải nén rất nhanh, thường được ứng dụng vào hệ thống phân tích hành vi người dùng theo thời gian thực.
    • Zstd (Zstandard): giống Gzip
    • none: không nén, giữ nguyên dữ liệu gốc, thường dùng cho data đã được nên trước đó hoặc nén là không hiệu quá như (hình ảnh JPEG, video)
  • Nén ở Producer: Tốt cho việc tiết kiệm băng thông mạng, kiểm soát linh hoạt thuật toán nén (hay dùng hơn)
  • Nén ở Topic: Tốt cho việc tiết kiệm dung lượng lưu trữ trên Broker và đảm bảo nén đồng nhất cho nhiều Producer. Phù hợp với các topic lưu trữ lâu dài hoặc khi Producer không thể thực hiện nén.