Bài 3: Consumer Group – Nghệ thuật "chia việc" để không bao giờ nấu trùng món

Chào người anh em! Sau khi đã có cái "bảng ghim" (Topic) và chia nó thành các cột nhỏ (Partition) ở bài trước, quán nhậu của chúng ta bây giờ trông cực kỳ chuyên nghiệp.

Nhưng vấn đề nảy sinh: Ai sẽ là người bốc giấy xuống để nấu? Nếu chỉ có một ông đầu bếp thì chia 3 cột cũng bằng thừa. Còn nếu thuê 5 ông mà không biết phân chia, họ sẽ giẫm chân lên nhau, hoặc tệ hơn là hai ông cùng nấu một đĩa cơm rang cho cùng một bàn.

Chào mừng ông đến với Bài 3: Consumer Group – Đội ngũ đầu bếp "không ai nhường ai" nhưng cực kỳ kỷ luật.

Trong Kafka, những ông đầu bếp đi lấy dữ liệu về xử lý được gọi là Consumer. Và khi các ông này kết hợp lại thành một đội để xử lý một Topic, chúng ta gọi đó là một Consumer Group.

Hãy tưởng tượng Consumer Group như một "Ca làm việc" (Shift).

1. Quy tắc "Một ghế chỉ một người ngồi"

Đây là quy tắc sắt đá nhất của Kafka: Trong cùng một Consumer Group, một Partition chỉ được phục vụ bởi duy nhất một Consumer.

Quay lại cái bảng ghim có 3 cột (3 Partitions) của mình:

1. Kịch bản A (1 đầu bếp): Một mình ông tả xung hữu đột, bốc giấy ở cả 3 cột. Chậm nhưng chắc, không sót đơn nào.
2. Kịch bản B (3 đầu bếp): Mỗi ông phụ trách một cột. Quá tuyệt vời! Tốc độ tối đa, ai làm việc nấy, không ai tranh của ai.
3. Kịch bản C (4 đầu bếp): 3 ông đứng ở 3 cột, ông thứ tư... đứng chơi xơi nước. Tại sao? Vì Kafka không cho phép hai ông cùng một nhóm nhảy vào một cột (để tránh việc nấu trùng món).

Mẹo cho ông: Nếu muốn tăng tốc độ xử lý, hãy tăng số lượng Partition trước, rồi mới tăng số lượng Consumer. Nếu Partition ít mà Consumer nhiều thì chỉ tốn tiền thuê "nhân viên" ngồi chơi thôi!

2. Group ID – "Ca sáng" và "Ca chiều" không liên quan gì nhau

Chuyện gì xảy ra nếu ông có một đội khác, ví dụ đội Kế toán, cũng muốn đọc cái bảng ghim đó để tính tiền vào cuối ngày? Lúc này, đội Kế toán sẽ lập một Consumer Group mới (có Group ID khác).

• Đội Đầu bếp đọc để nấu.
• Đội Kế toán đọc để tính tiền.

Hai đội này hoàn toàn độc lập. Việc đội Đầu bếp bốc tờ giấy đó đi không làm ảnh hưởng đến việc đội Kế toán vẫn thấy tờ giấy đó để ghi sổ. Kafka rất hào phóng, một tờ giấy ghim lên, bao nhiêu nhóm vào đọc cũng được, miễn là mỗi nhóm có một mục đích riêng.

3. "Consumer sập" và màn ảo thuật Rebalance

Đây là cái hay nhất của Kafka. Giả sử đang lúc cao điểm, ông đầu bếp phụ trách Cột 1 bỗng nhiên... đau bụng và chạy đi vệ sinh. Chẳng lẽ đơn hàng ở Cột 1 bị bỏ xửa?

Không hề! Kafka sẽ thấy "thằng đệ" này mất tích quá lâu (vượt quá thời gian timeout), nó sẽ ngay lập tức gào lên: "Ê mấy đứa kia, thằng Cột 1 nghỉ rồi, một đứa sang gánh hộ nó đi!".

Thế là một ông đầu bếp ở Cột 2 hoặc Cột 3 sẽ kiêm luôn Cột 1. Quá trình này gọi là Rebalance. Khi ông đầu bếp kia đi vệ sinh xong quay lại, Kafka lại "chia bài" lại để ai về chỗ nấy. Hệ thống luôn đảm bảo không có đơn hàng nào bị bỏ rơi.

Chốt lại bài học hôm nay:

• Consumer Group: Là một nhóm các Service cùng nhau "chia" một Topic ra để làm cho nhanh.
• Số Consumer <= Số Partition: Quy tắc vàng để không lãng phí tài nguyên.
• Group ID: Giúp các nhóm khác nhau (như Order, Billing, Analytics) đọc cùng một dữ liệu mà không đụng chạm nhau.
• Rebalance: Cơ chế "tự lành" giúp hệ thống vẫn chạy tốt dù có vài thằng "lăn ra chết".

Lời nhắn nhủ:

Khi thiết kế hệ thống, hãy luôn để mắt đến số lượng Partition. Nó giống như việc ông xây đường cao tốc vậy, càng nhiều làn (Partition) thì càng ít tắc xe, nhưng đòi hỏi ông phải có đủ xe (Consumer) để chạy trên đó.