1. Giới thiệu

Trong hệ sinh thái Kafka, broker đóng vai trò quan trọng trong việc xử lý các yêu cầu từ client, bao gồm các leader của partition, các replicas, và controller. Để đảm bảo tính hiệu quả và độ tin cậy, Kafka sử dụng giao thức TCP để quy định định dạng yêu cầu và cách thức broker phản hồi, cả trong trường hợp yêu cầu được xử lý thành công cũng như khi có lỗi xảy ra.

Client là thành phần khởi tạo kết nối và gửi yêu cầu đến broker. Một đặc điểm nổi bật của Kafka là quy trình xử lý yêu cầu: tất cả yêu cầu từ một client cụ thể sẽ được xử lý theo thứ tự nhận được, giúp đảm bảo thứ tự của các message được lưu trữ như một message queue.

2. Quy Trình Xử Lý Yêu Cầu

Mỗi yêu cầu tới broker đều bao gồm các tiêu chuẩn về header, bao gồm:

• Loại yêu cầu (API key): Xác định loại yêu cầu mà client đang gửi.
• Phiên bản yêu cầu: Giúp broker xử lý các client từ nhiều phiên bản khác nhau một cách chính xác.
• Correlation ID: Số định danh duy nhất cho yêu cầu, xuất hiện trong phản hồi và log lỗi để theo dõi và xử lý sự cố.
• Client ID: Để nhận diện ứng dụng đã gửi yêu cầu.

Broker lắng nghe trên từng cổng do đó sẽ khởi động một accpetor thread để tạo kết nối, và chuyển nó cho một processor thread để xử lý. Số lượng processor thread có thể được tùy chỉnh thông qua cấu hình. Các network thread chịu trách nhiệm lấy yêu cầu từ kết nối client, đặt chúng vào hàng đợi yêu cầu (request queue), và sau đó lấy phản hồi từ hàng đợi phản hồi (response queue) để gửi lại cho client.

Một số phản hồi có thể bị trì hoãn: các consumer có thể chỉ nhận được phản hồi khi có dữ liệu, trong khi các admin clients chỉ nhận được phản hồi cho yêu cầu DeleteTopic sau khi quá trình xóa topic đã bắt đầu. Những phản hồi bị trì hoãn này sẽ được giữ trong một vùng đệm (purgatory) cho đến khi có thể hoàn thành.

Các loại yêu cầu phổ biến từ client bao gồm:

• Produce requests: Gửi bởi các producer chứa các message mà client gửi tới broker.
• Fetch requests: Gửi bởi các consumer và các follower replicas để đọc message từ broker.
• Admin requests: Gửi bởi các admin client cho các thao tác metadata như tạo và xóa topic.

Các yêu cầu produce và fetch yêu cầu được gửi đến leader replicas của một partition. Nếu một broker nhận được produce requests cho một partition mà leader không nằm trên broker đó, client sẽ nhận được phản hồi lỗi "Không phải Leader cho partition". Tương tự, nếu fetch requests đến một broker không chứa leader của partition, lỗi sẽ xảy ra. Do đó, clients sẽ cần phải gửi yêu cầu đến broker chứa leader của partition tương ứng.

3. Làm Thế Nào Để Client Biết Nơi Gửi Yêu Cầu?

Để xác định broker nào cần gửi yêu cầu, client sử dụng yêu cầu metadata. Yêu cầu này cung cấp danh sách các topic mà client quan tâm và phản hồi từ server sẽ cho biết các partition, replicas và leader cho từng topic. Metadata có thể được gửi đến bất kỳ broker nào bởi vì mọi broker đều có bộ đệm metadata chứa thông tin này.

Client thường lưu trữ thông tin metadata trong bộ nhớ cache và sử dụng để gửi các yêu cầu produce và fetch đến broker phù hợp với từng partition. Tuy nhiên, thông tin này cần phải được làm mới định kỳ (thời gian làm mới được kiểm soát bởi tham số cấu hình metadata.max.age.ms). Nếu client nhận được lỗi "Not a Leader" cho yêu cầu của mình, client cần làm mới metadata trước khi gửi lại yêu cầu để tránh việc gửi yêu cầu đến broker không chính xác.

4. Thông Tin Kết Nối

Nếu bạn muốn thảo luận thêm về bài viết này, hãy kết nối với mình qua LinkedIn và Facebook:

• LinkedIn: https://www.linkedin.com/in/nguyentrungnam/
• Facebook: https://www.facebook.com/trungnam.nguyen.395/

Mong được kết nối và cùng bàn luận!
source: viblo