Đã đăng vào Chủ Nhật, 12:42 CH 9 phút đọc

Cơ Chế Replication Trong Kafka

1. Mở đầu

Replication (sao chép) là yếu tố cốt lõi trong kiến trúc của Kafka. Kafka thường được mô tả là “distributed, partitioned, replicated commit log service”. Replication đóng vai trò quan trọng vì nó giúp Kafka đảm bảo tính sẵn sàng và bền vững khi các node riêng lẻ gặp sự cố không thể tránh khỏi.

Như đã đề cập trước đó, dữ liệu trong Kafka được tổ chức theo các topics. Mỗi topic được chia thành các 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 thường 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

Có hai loại bản sao:

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

Bản sao follower (Follower replica): Tất cả các bản sao của một partition không phải là leader đều được gọi là follower. Trừ khi được cấu hình khác, 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 mà leader có. Nếu bản sao leader của một phân vùng gặp sự cố, một trong các bản sao follower sẽ được bầu thành leader mới cho partition đó.

3. Cơ chế sao chép

Tính năng đọc dữ liệu từ các bản sao follower được giới thiệu trong KIP-392 nhằm giảm network traffic costs bằng cách cho phép client tiêu thụ dữ liệu từ bản sao đồng bộ gần nhất thay vì từ bản sao leader. Để sử dụng tính năng này, cấu hình của consumer cần bao gồm client.rack, xác định vị trí của client. Cấu hình broker cần có replica.selector.class, với giá trị mặc định là LeaderSelector (luôn tiêu thụ từ leader). Tuy nhiên, có thể đặt thành RackAwareReplicaSelector, cho phép chọn một bản sao nằm trên broker có cấu hình rack.id khớp với client.rack của client. Ngoài ra, chúng ta cũng có thể triển khai logic chọn bản sao của riêng mình bằng cách thực hiện giao diện ReplicaSelector và sử dụng triển khai của riêng chúng ta.

Giao thức sao chép đã được mở rộng để đảm bảo rằng chỉ những commited message 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 độ tin cậy của dữ liệu vẫn được duy trì như khi lấy từ leader. Để đảm bảo điều này, tất cả các bản sao cần biết các message nào đã được cam kết bởi leader. Để thực hiện điều đó, leader gửi committed offset gần nhất cùng với dữ liệu cho follower. Việc gửi committed offset gần nhất này có thể gây ra một độ trễ nhỏ, do đó dữ liệu có thể có sẵn để tiêu thụ từ leader trước khi có sẵn trên follower.

Một nhiệm vụ khác của leader là xác định bản sao follower nào đang được cập nhật đúng với leader. Các follower cố gắng giữ đồng bộ bằng cách sao chép tất cả các message từ leader khi các message đến, nhưng chúng có thể không duy trì được đồng bộ vì nhiều lý do, chẳng hạn như khi tắc nghẽn mạng làm chậm quá trình sao chép hoặc khi một broker bị sự cố và tất cả các bản sao trên broker đó bắt đầu bị tụt lại phía sau cho đến khi broker được khởi động lại và chúng có thể tiếp tục sao chép.

Để giữ đồng bộ với leader, các bản sao gửi các yêu cầu Fetch tới leader, tương tự như các yêu cầu mà các consumer gửi để tiêu thụ message. Phản hồi các yêu cầu này, leader gửi các message đến các bản sao. Các yêu cầu Fetch chứa offset của message mà bản sao muốn nhận tiếp theo và luôn được gửi theo thứ tự. Điều này có nghĩa là leader có thể biết một bản sao đã nhận được tất cả các message cho đến message cuối cùng mà bản sao đó đã yêu cầu và không có message nào sau đó. Bằng cách kiểm tra offset cuối cùng mà mỗi bản sao yêu cầu, leader có thể xác định mức độ tụt lại của từng bản sao. Nếu một bản sao không yêu cầu message trong hơn 10 giây, hoặc nếu nó đã yêu cầu message nhưng không bắt kịp tin nhắn gần nhất trong hơn 10 giây, bản sao đó sẽ được coi là không đồng bộ. Nếu một bản sao không thể theo kịp với leader, nó sẽ không đủ điều kiện để trở thành leader mới trong trường hợp xảy ra sự cố—vì nó không chứa toàn bộ các message.

Ngược lại, các bản sao 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ộ. Chỉ các bản sao đồng bộ mới đủ điều kiện để được bầu làm leader của partition trong trường hợp leader hiện tại gặp sự cố.

Khoảng thời gian mà một follower có thể không hoạt động hoặc tụt lại trước khi bị coi là không đồng bộ được kiểm soát bởi tham số cấu hình replica.lag.time.max.ms. Sự trì hoãn này có ảnh hưởng đến hành vi của client và việc giữ lại dữ liệu trong quá trình bầu chọn leader. Trong các bài viết tới chúng ta sẽ bàn về việc đảm bảo độ tin cậy.

Ngoài leader hiện tại, mỗi partition còn có một leader ưu tiên—là bản sao đã là leader khi topic được tạo ra lần đầu tiên. Leader ưu tiên được ưa chuộng vì khi các partition được tạo, các leader được phân bổ đồng đều giữa các broker. Điều này có nghĩa là khi leader ưu tiên thực sự là leader cho tất cả các phân vùng trong cluster, tải sẽ được phân phối đồng đều giữa các broker. Theo mặc định, Kafka được cấu hình với auto.leader.rebalance.enable=true, điều này sẽ kiểm tra nếu bản sao leader ưu tiên không phải là leader hiện tại nhưng vẫn đồng bộ, và sẽ kích hoạt bầu chọn leader để làm cho leader ưu tiên trở thành leader hiện tại.

4. Tìm Các Leader Ưu Tiên

Cách tốt nhất để xác định leader ưu tiên hiện tại là kiểm tra danh sách các bản sao cho một partition. Bản sao đầu tiên trong danh sách luôn là leader ưu tiên. Điều này đúng bất kể ai là leader hiện tại và ngay cả khi các bản sao đã được phân bổ lại cho các broker khác bằng công cụ phân bổ lại bản sao. Thực tế, nếu chúng ta phân bổ lại các bản sao một cách thủ công, điều quan trọng là phải nhớ rằng bản sao chúng ta chỉ định đầu tiên sẽ là bản sao ưu tiên, vì vậy hãy chắc chắn rằng bạn phân bố chúng trên các broker khác nhau để tránh làm quá tải một số broker với các leader trong khi các broker khác không xử lý đủ khối lượng công việc của chúng.