Giải phẫu Kafka Producer: Nghệ thuật Đóng gói và Phân luồng hàng triệu Message mỗi giây

Chào anh em cộng đồng Viblo!

Trong các dự án Microservices, chúng ta thường hay nói với nhau: "Cứ ném data vào Kafka đi, bên kia sẽ có consumer lo". Câu nói này nghe thì nhàn, nhưng lại vô tình làm chúng ta lười tìm hiểu xem quá trình "ném" đó thực sự diễn ra như thế nào.

Kafka Producer không đơn thuần chỉ là một cái ống nước, cứ đổ nước vào là chảy. Nó giống như một trung tâm điều phối logistics khổng lồ. Và hôm nay, chúng ta sẽ mổ xẻ Nhiệm vụ lõi số 1 của Producer: Đóng gói và Phân loại (Routing).

Pha cà phê và cùng bắt đầu nhé! ☕

1. Nhiệm vụ chính: Đóng gói và Phân loại (Routing)

Producer không bao giờ gửi dữ liệu một cách "vô định hướng". Để một hệ thống khổng lồ hoạt động trơn tru mà không bị nghẽn, Producer phải hoàn thành xuất sắc 2 trách nhiệm lớn ngay từ khâu đầu vào.

A. Tạo bản tin (Message/Record Anatomy)

Khi bạn đẩy một giao dịch quẹt thẻ ở cổng AFC Metro hay một đơn hàng e-commerce vào Kafka, thứ thực sự chạy trên đường truyền mạng mạng (Network) không phải là một chuỗi JSON thuần túy. Nó được đóng gói thành một cấu trúc gọi là Record (Bản tin).

Một Record hoàn chỉnh trong Kafka bao gồm các thành phần cốt lõi sau:

1. Value (Nội dung chính): Đây là phần quan trọng nhất, chứa payload thực sự (ví dụ: chuỗi JSON chứa order_id, amount, status). Kafka coi Value chỉ là một mảng byte (byte array), nó không quan tâm bạn gửi JSON, XML hay String.
2. Key (Khóa - Tùy chọn nhưng cực kỳ quan trọng): Khóa dùng để định danh bản tin. Như ở bài "Out-of-order", việc dùng chung một Key (như order_id) sẽ ép Kafka đưa tất cả message của đơn hàng đó vào cùng một Partition, đảm bảo thứ tự tuyệt đối. Nếu không có Key, Kafka sẽ chia bài ngẫu nhiên (Round-Robin).
3. Timestamp (Thời gian): Được gán tự động khi Producer tạo ra message (CreateTime) hoặc khi Broker nhận được message (LogAppendTime). Cực kỳ hữu ích để xóa dữ liệu cũ (Retention) hoặc xử lý luồng (Stream Processing).
4. Headers (Siêu dữ liệu - Từ Kafka 0.11): Giống như HTTP Header. Bạn có thể nhét thêm các thông tin phụ như trace_id (để theo dõi log xuyên suốt Microservices) hoặc system_env (môi trường staging/prod) mà không làm rác phần Value chính.

B. Chỉ định Topic và Partition (Phân loại bưu cục)

Nhiệm vụ thứ hai của Producer là quyết định "gói hàng" này sẽ đi về đâu.

• Chỉ định Topic: Producer phải gọi tên chính xác Topic (chủ đề) mà bản tin thuộc về. (Ví dụ: afc_gate_transactions, user_login_logs, system_alerts).
• Chỉ định Partition (Bộ chia bài - Partitioner): Một Topic trong Kafka thường được chia làm nhiều Partitions để chạy song song. Producer có một module ngầm gọi là Partitioner.
• Nếu bạn tự chỉ định ID Partition (ít dùng): Message vào thẳng Partition đó.
• Nếu bạn truyền Key: Partitioner sẽ băm (hash) cái Key đó ra, chia lấy dư cho tổng số Partition để quyết định.
• Nếu không có Key: Gửi ngẫu nhiên vòng tròn (Round-Robin) cho đều tải.

2. Code Demo (Thực chiến đóng gói Message)

Lý thuyết suông thì khó nhớ. Hãy xem cách một Senior Backend Developer đóng gói một Message hoàn chỉnh trong Laravel (sử dụng package junges/kafka) thay vì chỉ ném bừa một mảng JSON.

Code "Ngây thơ" (Chỉ gửi Value):

// Gửi ngẫu nhiên, không có Key, không có Header, dễ gây sai thứ tự
Kafka::publishOn('afc_gate_transactions')
 ->withBody(['ticket_id' => 'TK123', 'station' => 'Ben Thanh', 'status' => 'IN'])
 ->send();

Code "Hạng nặng" (Đóng gói hoàn chỉnh):

use Junges\Kafka\Message\Message;
use Junges\Kafka\Facades\Kafka;

$ticketId = 'TK123';
$payload = [
 'ticket_id' => $ticketId,
 'station' => 'Ben Thanh',
 'status' => 'IN',
 'timestamp' => now()->timestamp,
];

// 1. Khởi tạo một Record hoàn chỉnh với đầy đủ "vũ khí"
$message = new Message(
 headers: [
 'trace_id' => request()->header('X-Trace-Id', uniqid()), // Gắn Trace ID để dễ debug tracking
 'source' => 'gate_terminal_01'
 ],
 body: $payload,
 key: $ticketId // <-- QUAN TRỌNG: Dùng Ticket ID làm Key để hash vào đúng 1 Partition
);

// 2. Chỉ định Topic và Gửi
Kafka::publishOn('afc_gate_transactions')
 ->withMessage($message)
 ->send();

Với cách viết này, gói hàng của bạn đã có dán nhãn mác (Header), có định tuyến (Key) và nội dung (Body). Hệ thống xử lý phía sau sẽ cực kỳ nhàn rỗi.

3. Kinh nghiệm xương máu: "Gom hàng" trước khi gửi (Batching)

Nếu hệ thống của bạn có 1000 lượt quẹt thẻ mỗi giây, việc Producer tạo ra 1000 kết nối mạng (Network calls) để gửi từng message lên Broker là một thảm họa, làm sập băng thông và cháy CPU của Broker.

Kafka Producer sinh ra để làm việc hạng nặng nhờ 2 cấu hình bí mật: batch.size và linger.ms.

Thay vì gửi ngay lập tức, Producer sẽ gom các message vào một "chuyến xe tải" (Batch) nằm tạm trên RAM của server gửi:

1. batch.size: Thể tích tối đa của thùng xe tải (Mặc định 16KB). Xe đầy là chạy.
2. linger.ms: Thời gian tài xế ngồi chờ khách (Mặc định 0ms - tức là có khách chạy luôn). Nếu bạn set linger.ms = 10 (10 mili-giây), Producer sẽ cố đợi gom thêm message trong 10ms rồi mới gửi đi một lần.

Tuyệt chiêu: Chỉ cần hi sinh 10 mili-giây độ trễ (linger.ms=10), bạn có thể gom được hàng chục/hàng trăm message vào chung 1 Request mạng. Throughput (Thông lượng) của hệ thống sẽ tăng lên gấp hàng chục lần mà CPU lại giảm xuống!

4. Lời kết

Việc hiểu sâu cấu trúc của một Message (Key, Value, Header) và cách Producer định tuyến (Partitioner) sẽ phân biệt bạn là một người "chỉ biết dùng tool" hay là một Kỹ sư hệ thống (System Engineer) thực thụ.

Lần tới khi code chức năng đẩy data lên Kafka, hãy dừng lại 1 giây và tự hỏi: "Message này có cần Key không? Mình có nên gắn Header Trace ID vào để sau này debug cho dễ không?"

Anh em có hay dùng Header trong Kafka chưa, hay toàn nhét hết cẩm phả vào trong file JSON body? Cùng chém gió ở phần bình luận nhé!

Chúc anh em code sạch và server luôn mát!