1. Giới Thiệu

Replication (sao chép) chính là một trong những yếu tố then chốt trong kiến trúc của Kafka. Kafka được mô tả như một "dịch vụ log cam kết phân tán, phân vùng và sao chép". Chức năng replication không chỉ giúp đảm bảo tính sẵn sàng mà còn duy trì tính bền vững của hệ thống khi các node gặp sự cố không thể tránh được.

Dữ liệu trong Kafka được tổ chức theo các topics. Mỗi topic được chia thành nhiều partitions, và mỗi partition có thể có nhiều bản sao (replicas). Những bản sao này được lưu trữ trên các broker, và mỗi broker có thể lưu trữ hàng trăm hoặc thậm chí hàng nghìn bản sao thuộc các topic và partition khác nhau.

2. Các Loại Bản Sao

Trong Kafka, có hai loại bản sao:

Bản sao leader (Leader replica): Mỗi partition chỉ định một bản sao duy nhất là leader. Tất cả các yêu cầu ghi (produce requests) phải được gửi đến bản sao leader để đảm bảo tính nhất quán. Người dùng có thể tiêu thụ dữ liệu từ bản sao leader hoặc từ các bản sao follower.

Bản sao follower (Follower replica): Các bản sao không phải là leader được gọi là follower. Theo mặc định, các follower không phục vụ yêu cầu của khách hàng; nhiệm vụ chính của chúng là sao chép các message từ leader và cập nhật với các message mới nhất. Nếu bản sao leader gặp sự cố, một trong các bản sao follower sẽ được bầu làm leader mới cho partition đó.

3. Cơ Chế Sao Chép

Tính năng cho phép đọc dữ liệu từ các bản sao follower được giới thiệu trong KIP-392 để giảm chi phí băng thông mạng. Thay vì chỉ tiêu thụ từ bản sao leader, client có thể tiêu thụ từ bản sao đồng bộ gần nhất. Để sử dụng tính năng này, cấu hình của consumer cần có client.rack, xác định vị trí của client, trong khi broker cần cấu hình replica.selector.class. Giá trị mặc định là LeaderSelector, nhưng có thể đặt thành RackAwareReplicaSelector để chọn bản sao nằm trên broker có rack.id khớp với client.rack.

Giao thức sao chép cũng được mở rộng để đảm bảo rằng chỉ những message đã được cam kết mới có sẵn khi tiêu thụ từ một bản sao follower. Điều này đảm bảo rằng dữ liệu vẫn đáng tin cậy như khi lấy từ leader. Để đạt được điều này, leader gửi offset đã cam kết gần nhất cùng với dữ liệu cho follower. Tuy nhiên, việc gửi offset này có thể gây ra một chút độ trễ, nghĩa là dữ liệu có thể có sẵn từ leader trước khi được cập nhật trên follower.

Leader cũng có nhiệm vụ theo dõi các follower để xác định bản sao nào đang đồng bộ đúng với leader. Các follower cố gắng sao chép các message từ leader ngay khi chúng đến. Tuy nhiên, một số lý do như tắc nghẽn mạng có thể làm cho chúng không thể duy trì sự đồng bộ. Nếu một follower không yêu cầu message trong hơn 10 giây hoặc tụt lại phía sau, nó sẽ được coi là không đồng bộ và không đủ điều kiện trở thành leader mới.

Các bản sao theo kịp và liên tục yêu cầu các message mới nhất được gọi là các bản sao đồng bộ, và chỉ những bản sao này mới có thể được bầu làm leader trong trường hợp leader hiện tại gặp sự cố. Thời gian tối đa một follower có thể không hoạt động trước khi bị coi là không đồng bộ được chi phối bởi tham số cấu hình replica.lag.time.max.ms.

Ngoài leader hiện tại, mỗi partition còn có một leader ưu tiên - bản sao đầu tiên đã là leader khi topic được tạo. Leader ưu tiên được ưa chuộng vì nó giúp phân phối tải đồng đều giữa các broker. Kafka được cấu hình mặc định với auto.leader.rebalance.enable=true, cho phép bầu chọn leader mới nếu leader ưu tiên không phải là leader hiện tại nhưng vẫn đồng bộ.

4. Xác Định các Leader Ưu Tiên

Cách tốt nhất để xác định leader ưu tiên của một partition là xem xét danh sách các bản sao. Bản sao đầu tiên trong danh sách luôn là leader ưu tiên, bất kể ai là leader hiện tại. Khi phân bổ lại các bản sao, hãy chắc chắn rằng bản sao ưu tiên được đặt trên các broker khác nhau để tránh làm quá tải một số broker.

5. Kết Nối

Nếu bạn muốn trao đổi thêm về chủ đề này, hãy kết nối với tôi qua LinkedIn và Facebook:

• LinkedIn: Nguyễn Trung Nam
• Facebook: Trung Nam Nguyễn

Rất mong được kết nối và cùng thảo luận!
source: viblo