Bạn đã đi qua những khái niệm cốt lõi nhất về kiến trúc và các cơ chế bảo vệ sự an toàn của Kafka. Khi mang Kafka vào thực chiến, đặc biệt là với các hệ thống backend chịu tải cao, kiến trúc chuẩn là chưa đủ. Bạn cần biết cách "độ xe" (Tuning) để hệ thống chạy mượt nhất theo đúng nhu cầu.
Chào mừng bạn đến với Bài 9.
Trong thế giới hệ thống phân tán, có hai khái niệm luôn đi ngược chiều nhau:
- Độ trễ (Latency): Thời gian tính từ lúc gửi một tin nhắn cho đến khi nó được xử lý xong. (Yêu cầu phải cực kỳ nhanh, tính bằng mili-giây).
- Băng thông (Throughput): Số lượng tin nhắn hệ thống có thể xử lý trong một giây. (Yêu cầu phải cực kỳ nhiều, tính bằng triệu bản tin/giây).
Bạn không thể có cả hai ở mức tối đa cùng một lúc. Khi cấu hình Kafka, bạn phải chọn ưu tiên một trong hai dựa trên bài toán thực tế.
1. Tối ưu phía Producer (Người gửi)
Thay vì gửi lẻ tẻ từng tin nhắn qua mạng (rất tốn tài nguyên và dễ nghẽn cổ chai), Kafka Producer có cơ chế Batching (Gom lô). Hãy tưởng tượng việc này giống như vận hành xe buýt:
Thay vì gửi lẻ tẻ từng tin nhắn qua mạng (rất tốn tài nguyên và dễ nghẽn cổ chai), Kafka Producer có cơ chế Batching (Gom lô). Hãy tưởng tượng việc này giống như vận hành xe buýt:
batch.size(Kích thước lô): Sức chứa tối đa của chiếc xe buýt (tính bằng byte). Ví dụ: Cấu hình 16KB.linger.ms(Thời gian chờ): Thời gian xe buýt chịu đứng đợi ở bến trước khi khởi hành, dù chưa đầy khách. Ví dụ: Cấu hình 10ms.
Chiến lược cấu hình:
| Mục tiêu tối ưu | Cấu hình tham khảo | Áp dụng thực tế |
|---|---|---|
| Ưu tiên Độ trễ thấp (Low Latency) | linger.ms = 0, batch.size nhỏ | Phù hợp với các hệ thống như cổng kiểm soát vé tự động (AFC). Khách quẹt thẻ là xe buýt chạy ngay, không chờ đợi, đảm bảo cửa mở lập tức. Nhược điểm là tốn băng thông mạng. |
| Ưu tiên Băng thông cao (High Throughput) | linger.ms = 10 đến 100, batch.size lớn (VD: 64KB) | Phù hợp với hệ thống xử lý Log hoặc Thống kê. Đợi 10ms để gom được 1000 tin nhắn rồi gửi đi cùng lúc. Độ trễ tăng thêm 10ms nhưng số lượng tin nhắn xử lý được mỗi giây tăng vọt. |
Bí kíp Backend: Hãy kết hợp thêm tham số compression.type (chọn lz4 hoặc zstd). Việc nén nguyên một lô dữ liệu (batch) trước khi gửi qua mạng sẽ giúp giảm thiểu đáng kể chi phí I/O của ổ cứng và mạng, tăng tốc độ tổng thể lên rất nhiều.
2. Tối ưu phía Consumer (Người nhận)
Bên phía lấy dữ liệu, bạn cũng phải kiểm soát tốc độ để ứng dụng của mình không bị "bội thực".
fetch.min.bytes: Khối lượng dữ liệu tối thiểu mà Broker phải gom đủ mới trả về cho Consumer. (Giúp giảm số lượng vòng lặp đi hỏi Broker khi hệ thống ít dữ liệu).max.poll.records: Giới hạn số lượng tin nhắn tối đa Consumer lấy về trong mỗi lần gọi hàm.- Tại sao quan trọng? Nếu bạn để quá lớn (VD: lấy 10,000 bản tin một lúc), logic xử lý của bạn sẽ chạy rất lâu. Kafka có một tham số là
max.poll.interval.ms(thời gian tối đa giữa các lần gọi). Nếu bạn xử lý lâu quá mức này, Kafka sẽ tưởng Consumer của bạn đã "chết lâm sàng", và kích hoạt cơ chế đá Consumer này ra khỏi Group, gây gián đoạn hệ thống.
Tóm tắt công thức chuẩn
- Cho hệ thống giao dịch (Transaction/Real-time): Gửi đi ngay lập tức (
linger.ms=0), xác nhận an toàn tuyệt đối (acks=all), ưu tiên xử lý từng tin nhắn để tránh sai lệch dữ liệu. - Cho hệ thống thống kê/Log (Analytics/Logging): Gom lô lớn (
linger.ms>10,batch.sizelớn), nén dữ liệu (compression.type=lz4), chỉ cần Leader nhận được là xong (acks=1).
Đến đây, bạn đã hoàn thiện gần như toàn bộ bức tranh lý thuyết từ kiến trúc, hệ sinh thái, bảo mật dữ liệu đến tối ưu hiệu năng của Apache Kafka.
