Kafka Producer Advanced
Last updated
Last updated
ACK (viết tắt của Acknowledgment) là tính hiệu được gửi từ nơi nhận tính hiệu để báo rằng tính hiệu đã được nhận thành công.
Trong Kafka, tham số acks (acknowledgments) quyết định mức độ xác nhận mà Producer yêu cầu từ Kafka Broker trước khi coi một bản ghi là "đã gửi thành công". Giá trị của acks là số lượng tính hiệu producer yêu cầu leader phải nhận trước khi Producer xác nhận bản ghi đã gửi thành công
Producer không yêu cầu ACKs từ leader
Các record được sao chép một cách bất đồng bộ (Asynchronous)
Ưu điểm: Tốc độ cao nhất, độ trễ thấp.
Nhược điểm:
Không đảm bảo độ tin cậy (Durability: weakest)
Nếu Broker không nhận được bản ghi (do lỗi mạng, Broker sập, v.v.), Producer sẽ không biết và bản ghi có thể bị mất.
Không có thông tin offset vì Broker không gửi phản hồi.
Use case: các trường hợp cần tải lớn
IoT devices: độ ẩm, nhiệt độ
Log không quá quan trọng
Producer chỉ yêu cầu ACKs từ leader
Các record được sao chép một cách bất đồng bộ (Asynchronous)
Ưu điểm:
Cân bằng giữa tốc độ và độ tin cậy.
Có thông tin offset vì Leader Broker gửi phản hồi.
Nhược điểm:
Nếu Leader sập ngay sau khi xác nhận mà bản ghi chưa được sao chép sang các Follower (replica), bản ghi có thể bị mất.
Use case:
Tracking hành vi của User
Thống kê lượt click, view
Producer chờ tới khi Leader nhận ACKs từ tất cả In-Sync Replica (ISRs)
Các record được sao chép một cách đồng bộ (synchronous)
Ưu điểm:
Độ tin cậy cao nhất, đảm bảo không mất dữ liệu trừ khi toàn bộ cluster sập.
Nhược điểm:
Độ trễ cao hơn do phải chờ nhiều xác nhận.
Use case: các hệ thống cần tính toàn vẹn dữ liệu cao
Hệ thống tài chính
Mua hàng, thanh toán
Khi Producer gửi message và nhận lỗi, bước đầu tiên bắt buộc phải thực hiện là retry (thử gửi lại). Đây là nguyên tắc quan trọng để đảm bảo tính tin cậy (reliability) của hệ thống Kafka.
Các loại lỗi trong Kafka:
Retriable error: LEADER_NOT_AVAILABLE, lỗi mạng (NetworkException), timeout,…
Non-retriable error: INVALID_CONFIG, RECORD_TOO_LARGE, INVALID_TOPIC_EXCEPTION
Xử lý lỗi:
Auto: tự động retry N lần.
Manual
Giá trị mặc định của Retry:
Kafka ≤ 2.0: là 0
Kafka ≥ 2.1: 0 đến 2147483647
Recommend retries: 30 lần
Vấn đề khi retry:
Duplicate dữ liệu: Producer không nhận được ACKs dù leader đã gửi về → retry → duplicate dữ liệu
Sai thứ tự khi gửi: Gửi 1 2 3 4 tuy nhiên retry lại 2 nên gửi thứ tự là 1 3 4 2.
Batching (đóng gói message thành batch) là cơ chế gom nhiều message thành một nhóm (batch) trước khi gửi từ Producer đến Broker, giúp tăng throughput (tốc độ xử lý) và giảm overhead (chi phí mạng, I/O).
Batching được triển khai bởi producer
Mỗi khi ghi kafka sẽ ghi 1 lô (batch) gồm nhiều record chứ không ghi riêng lẻ.
Mỗi 1 batch sẽ được ghi vào 1 partition.
Các thông số cấu Hình Batching trong Kafka Producer
batch.size: mặc định là 16KB. Là kích thước tối đa của một batch, khi đạt ngưỡng này sẽ gửi đi ngay. Nếu một message có kích thước lớn hơn batch.size thì sẽ được gửi độc lập.
linger.ms: mặc định là 0 (không chờ). Thời gian tối đa chờ để đóng batch (ms), khi hết thời gian dù có đủ hay chưa cũng sẽ gửi.
buffer.memory: mặc định 32MB. Tổng bộ nhớ đệm cho các batch chưa gửi.
Lưu ý:
Đánh đổi: tăng thông lượng nhưng cũng tăng độ trễ
Broker sẽ ghi nguyên batch xuống ỗ đĩa chứ không ghi từng record → cải thiện hiệu năng làm việc với disk.
Compression (nén dữ liệu) là cơ chế giảm kích thước message trước khi gửi từ Producer đến Broker, giúp:
Tiết kiệm băng thông (network bandwidth).
Giảm dung lượng lưu trữ trên Broker.
Tăng throughput (do truyền tải ít dữ liệu hơn).
Khi kết hợp với Batching thì tỉ lệ nén sẽ cao hơn. Có thể từ 5 đến 7 lần.
Nhược điểm:
Tốn tài nguyên như CPU
Kafka hỗ trợ nhiều thuật toán nén, mỗi loại có đánh đổi giữa tốc độ và tỉ lệ nén:
Algorithm
Config Value
Tốc độ
Tỉ lệ nén
CPU Usage
GZIP
gzip
Chậm
Cao
Cao
Snappy
snappy
Trung bình
Trung bình
Trung bình
LZ4
lz4
Rất nhanh
Thấp
Rất thấp
Zstandard
zstd
Trung bình
Trung bình
Trung bình
→ Thiết lập thông qua compression.type ở:
Consumer: không cần cấu hình.
Trường hợp sử dụng:
Gzip: Dữ liệu log, JSON, hoặc các tập dữ liệu lớn cần lưu trữ lâu dài.
Snappy/LZ4: Streaming dữ liệu thời gian thực, như IoT hoặc hệ thống phân tích nhanh.
Zstandard: Các ứng dụng cần cả hiệu suất cao và tiết kiệm không gian.
None: Dữ liệu nhỏ hoặc khi băng thông không phải là vấn đề.
Quá trình nén dữ liệu được thực hiện bởi Producer, trong khi Consumer đảm nhiệm việc giải nén.
Theo mặc định, Broker không can thiệp hay thay đổi batch dữ liệu. Tuy nhiên, có thể cấu hình để Broker giải nén và nén lại dữ liệu trước khi lưu trữ, mặc dù điều này không được khuyến nghị trừ một số trường hợp đặc biệt như:
Chuyển đổi thuật toán nén
Kiểm tra hoặc chuẩn hóa dữ liệu: kiểm tra toàn vẹn dữ liệu
Tối ưu hóa lưu trữ dài hạn: cần 1 thuật toán nén tốt hơn để lưu trữ lâu dài.
Tương thích với các Consumer khác nhau: nếu consumer không tương thích với thuật toán nén của producer.
max.in.flight.requests.per.connection: Đây là số lượng tối đa các yêu cầu gửi dữ liệu (requests) mà Producer có thể gửi đến Broker trên một kết nối mà không cần chờ phản hồi (acknowledgment) từ Broker.
Tức là thay vì đợi đến khi có acks rồi mới tiếp tục nhận request thì cho phép nhận tiếp request. Điều này giúp tăng khả năng xử lý và thông lượng của producer.
Default: 5
Round Robin Partitioner
Sticky Partitioner
Round Robin kết hợp với Batching. Ở trường hợp này message không được gửi ngay lập tức mà được gửi vào 1 Batch tương ứng với từng Partition. Sau khi gom đủ thì mới gửi Batch theo logic Round Robin.
Sticky Partition: Chọn ra một Partition → tạo ra 1 Batch → gom record → gửi đi. Sau đó tiếp tục random chọn ra partition tiếp theo.
Hạn chế được số lượng Batch
Size của Batch lớn hơn → tối ưu hơn
→ Round Robin là Round Robin theo record, Sticky là “Round Robin theo Batch”.
Idempotence (tính bất biến) trong Apache Kafka là một tính năng quan trọng giúp đảm bảo rằng các message sẽ chỉ được ghi vào broker Kafka đúng một lần, ngay cả khi producer gửi lại cùng một message nhiều lần do lỗi mạng hoặc các vấn đề khác.
Khi idempotence được bật (đặt enable.idempotence=true), Kafka Producer sẽ:
Gán mỗi message một sequence number (số thứ tự) duy nhất
Broker sẽ theo dõi số thứ tự này cho mỗi producer
Nếu broker nhận được message với số thứ tự đã xử lý trước đó, nó sẽ bỏ qua thay vì ghi lại
: 100ms là giá trị đợi trước khi retry : 120000 là thời gian retry tối đa (2 phút)
Producer: Tệp cấu hình hay code.
Broker: Tệp
