Bài 5: Cơ chế Replication — Bí quyết sống sót khi "cháy ổ cứng"

Ở Bài 4, ta đã giải quyết rủi ro sập ứng dụng Consumer. Còn bây giờ, ta nói về thảm họa hạ tầng: Máy chủ Kafka (Broker) bị cháy ổ cứng, đứt cáp nguồn, hoặc chết đột ngột. Để không mất một byte dữ liệu nào, Kafka áp dụng chiến lược "không bao giờ bỏ tất cả trứng vào một rổ".

Chào mừng bạn đến với Bài 5.

Để dữ liệu an toàn tuyệt đối, Kafka sử dụng cơ chế Replication (Nhân bản).

1. Replication Factor (Hệ số nhân bản) là gì?

Khi tạo ra một Topic, bạn không chỉ khai báo số lượng Partition (để tăng tốc độ đọc/ghi như ở Bài 2), mà còn phải cấu hình một tham số cực kỳ quan trọng: Replication Factor (RF).

• Giả sử bạn cài đặt Replication Factor = 3.
• Điều này có nghĩa là mỗi Partition của Topic đó sẽ được Kafka ngầm copy ra thành 3 bản sao giống hệt nhau, và cất giữ trên 3 máy chủ Broker vật lý khác nhau.
• Nếu 1 hoặc thậm chí 2 máy chủ bị cháy ổ cứng cùng lúc, bạn vẫn còn 1 bản nguyên vẹn ở máy chủ thứ 3.

2. Leader và Follower: Ai làm việc, ai đứng nhìn?

Dù có 3 bản sao, nhưng để tránh việc dữ liệu bị ghi lộn xộn, Kafka phân chia giai cấp rất rõ ràng:

• Leader (Bản chính): Trong 3 bản sao đó, Kafka sẽ bầu ra duy nhất một bản làm Leader.
• Quy tắc thép: Producer chỉ gửi dữ liệu vào Leader, và Consumer cũng chỉ lấy dữ liệu từ Leader.
• Follower (Bản phụ): Các bản sao còn lại trên các Broker khác đóng vai trò Follower. Nhiệm vụ duy nhất của chúng là liên tục "nhìn" sang Leader và copy (đồng bộ) dữ liệu về máy mình càng nhanh càng tốt.

Kịch bản thảm họa: Nếu Broker chứa Partition Leader đột ngột bốc cháy thì sao?

1. Các Follower ngay lập tức phát hiện Leader đã mất tích.
2. Một cuộc "bầu cử" thần tốc diễn ra. Kafka sẽ chọn ra một Follower cập nhật đầy đủ dữ liệu nhất để thăng cấp lên làm Leader mới.
3. Hệ thống tiếp tục nhận và trả dữ liệu bình thường, gần như không có độ trễ (downtime).

3. ACKS (Biên lai giao hàng) — Quyết định sống còn của Backend Developer

Cơ chế Leader - Follower là do hạ tầng tự lo, nhưng với vai trò lập trình viên, việc cấu hình ứng dụng Producer của bạn gửi dữ liệu thế nào mới là chốt chặn cuối cùng. Bạn phải kiểm soát thông số acks (Acknowledgments - Xác nhận).

Đây là 3 mức độ "lấy sinh mạng ra đảm bảo" khi gửi tin vào Kafka:

• acks=0 (Bắn và quên): Producer ném tin nhắn đi và coi như xong, không thèm chờ leader xác nhận
• Ưu điểm: Cực kỳ nhanh
• Rùi ro: Bị rớt mạng giữa đường hoặc Broker chết là mất trắng (thường dùng để log hệ thống).
• acks=1 (Chỉ Leader xác nhận): Producer đợi Leader nhận xong và ghi vào ổ cứng thì báo thành công.
• Rủi ro ẩn giấu: Giả sử Leader vừa báo thành công cho Producer xong thì... bùm, cháy ổ cứng. Lúc này Follower chưa kịp copy dữ liệu sang. Tin nhắn đó vĩnh viễn biến mất dù ứng dụng của bạn tưởng là đã gửi xong.
• acks=all (Tất cả cùng xác nhận): Producer gửi tin vào Leader. Leader không báo thành công ngay, mà phải đợi tất cả các Follower copy xong xuôi, ghi vào đĩa an toàn, rồi Leader mới báo cho Producer là "Đã nhận hàng thành công".
• Lưu ý: Tốc độ sẽ chậm hơn một chút vì phải chờ đợi mạng nội bộ giữa các Broker, nhưng đổi lại là độ an toàn 100%.

Ứng dụng thực tế: Trong việc thiết kế kiến trúc cho các hệ thống quản lý thu phí, cổng rào chắn tự động hay giao dịch soát vé, tính toàn vẹn của luồng dữ liệu (Data Integrity) là tối thượng. Bạn không thể để mất một giao dịch quẹt thẻ nào chỉ vì server bị sập. Do đó, việc cấu hình acks=all kết hợp Replication Factor >= 3 là tiêu chuẩn ngành bắt buộc.

Đến đây, hệ thống của chúng ta đã vừa nhanh (Partition), vừa tự nhớ vị trí (Offset), vừa bất tử (Replication).

Tuy nhiên, có hàng tá Broker, hàng trăm Partition, ai sẽ là người đứng ra làm "tổng chỉ huy" để biết Broker nào chết mà tổ chức bầu Leader mới? Chúng ta cùng giải mã nhân vật đứng trong bóng tối này ở Bài 6 nhé?