ở Bài 5 chúng ta đã thấy hệ thống Broker hoạt động rất nhịp nhàng để sao lưu và bảo vệ dữ liệu. Nhưng Broker thực chất chỉ là những "người công nhân" lưu trữ. Để hàng chục "công nhân" này không giẫm chân lên nhau, Kafka cần một "tổng chỉ huy".
Trong một hệ thống phân tán gồm nhiều máy chủ, sẽ luôn có những câu hỏi đau đầu:
- Máy chủ Broker số 3 vừa bị sập, ai sẽ báo cho toàn hệ thống biết?
- Partition A bị mất Leader, ai có quyền quyết định Follower nào được lên thay thế?
- Thông tin cấu hình của hàng trăm Topic được cất ở đâu để đồng bộ trên toàn mạng lưới?
Để giải quyết, Kafka cần một cơ chế đồng thuận (Consensus). Tại đây có một sự dịch chuyển công nghệ cực kỳ quan trọng mà mọi Backend Developer đều cần nắm bắt để không xây dựng hệ thống lỗi thời: Sự thoái trào của ZooKeeper và sự lên ngôi của KRaft.
1. Kỷ nguyên cũ: Dựa dẫm vào Apache ZooKeeper
Từ những ngày đầu tiên đến phiên bản 2.7, Kafka không tự mình làm "tổng chỉ huy" mà phải sử dụng một phần mềm bên ngoài tên là ZooKeeper.
- Cách hoạt động: ZooKeeper giống như một cuốn sổ hộ tịch và một vị quan tòa. Nó lưu giữ toàn bộ siêu dữ liệu (Metadata) của Kafka (Broker nào đang sống, ai đang làm Leader, cấu hình hệ thống ra sao).
- Điểm yếu chí mạng: Quản lý Kafka đã khó, nay bạn phải duy trì và bảo mật thêm cụm ZooKeeper (một hệ thống phân tán tách biệt hoàn toàn). Khi hệ thống phình to lên hàng trăm ngàn Partition, ZooKeeper trở thành nút thắt cổ chai vì nó xử lý metadata quá chậm, làm thời gian bầu lại Leader bị kéo dài.
2. Kỷ nguyên mới: Tự chủ với KRaft (Kafka Raft)
Nhận ra sự cồng kềnh đó, những người tạo ra Kafka đã quyết định phẫu thuật cắt bỏ hoàn toàn ZooKeeper. Bắt đầu từ bản Kafka 3.3, KRaft (Kafka Raft Metadata mode) chính thức trở thành kiến trúc tiêu chuẩn.
Thay vì dựa vào hệ thống bên ngoài, KRaft chọn ra một vài Broker ngay trong cụm (Cluster) để đóng vai trò là Quorum Controller.
- Các Controller này tự động bầu ra một Chỉ huy trưởng (Active Controller).
- Mọi sự thay đổi về trạng thái hệ thống (VD: thêm Broker, tạo Topic mới) đều được coi là những "tin nhắn" (events) và được lưu trữ ngay vào trong một Topic nội bộ đặc biệt của Kafka (gọi là Metadata Topic).
- Tóm lại: Kafka sử dụng chính sức mạnh stream dữ liệu của mình để quản lý... chính nó.
| Tiêu chí | Cụm Kafka dùng ZooKeeper (Cũ) | Cụm Kafka dùng KRaft (Mới) |
|---|---|---|
| Kiến trúc | Phức tạp (Cần quản lý 2 hệ thống song song) | Tối giản (Chỉ duy nhất một tiến trình Kafka) |
| Sức chịu tải | Quá tải khi đạt ngưỡng vài trăm ngàn Partition | Xử lý mượt mà hàng triệu Partition |
| Tốc độ phục hồi | Khởi động chậm do phải đồng bộ trạng thái từ xa | Cực nhanh vì trạng thái lưu trực tiếp trên log nội bộ |
Lời khuyên thiết kế hệ thống: Nếu bạn đang chuẩn bị dựng một cụm Kafka mới để phục vụ các dự án đòi hỏi luồng dữ liệu thời gian thực và tính chính xác cao, hãy bỏ qua cấu hình ZooKeeper và chọn triển khai hoàn toàn bằng KRaft mode. Việc này giúp giảm hẳn một nửa gánh nặng DevOps và tăng tính ổn định cho toàn bộ hạ tầng.
Tới đây, bạn đã đi qua trọn vẹn phần Kiến trúc Lõi của Kafka (Broker, Topic, Partition, Offset, Consumer Group, Replication, và KRaft). Bộ khung đã vững chắc, phần tiếp theo là cách chúng ta giao tiếp và đưa dữ liệu vào/ra khỏi nó.
