1. Mở đầu

Phần lớn công việc của một broker Kafka là xử lý các yêu cầu được gửi đến các leader của partition từ các client, các partition replicas và controller. Kafka sử dụng giao thức TCP để quy định định dạng của các yêu cầu và cách broker phản hồi lại kết quả bao gồm cả khi yêu cầu được xử lý thành công hay khi broker gặp lỗi trong quá trình xử lý.

Client luôn khởi tạo kết nối và gửi yêu cầu, sau đó broker xử lý các yêu cầu và phản hồi. Tất cả các yêu cầu được gửi tới broker từ một client cụ thể sẽ được xử lý theo thứ tự chúng được nhận—điều này đảm bảo rằng Kafka hoạt động như một message queue và đảm bảo về thứ tự cho các message mà nó lưu trữ.

2. Quá trình xử lý yêu cầu

Tất cả các yêu cầu đều có tiêu chuẩn về header bao gồm: Loại yêu cầu (còn gọi là API key)

Phiên bản yêu cầu (giúp broker có thể xử lý các client từ nhiều phiên bản khác nhau và phản hồi phù hợp)

Correlation ID: một số định danh duy nhất cho yêu cầu, xuất hiện cả trong phản hồi và log lỗi (được sử dụng để theo dõi và khắc phục sự cố)

Client ID: dùng để nhận diện ứng dụng đã gửi yêu cầu

Với mỗi port mà broker lắng nghe, broker sẽ chạy một acceptor thread để tạo kết nối và chuyển nó cho một processor thread để xử lý. Số lượng processor thread (còn được gọi là network thread) có thể tùy chỉnh bằng cấu hình. Các network thread chịu trách nhiệm lấy các yêu cầu từ các kết nối client đẩy chúng vào hàng đợi yêu cầu (request queue), sau đó lấy các phản hồi từ hàng đợi phản hồi (response queue) và gửi lại cho client. Đôi khi, các phản hồi cho client cần phải bị trì hoãn—các consumer chỉ nhận được phản hồi khi có dữ liệu, và 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. Các phản hồi bị trì hoãn này sẽ được giữ trong một vùng đệm (purgatory) cho đến khi chúng có thể được hoàn thành. Hình 1. Quá trình xư lí yêu cầu trong kafka

Khi các yêu cầu được đẩy vào hàng đợi yêu cầu, các I/O thread (còn gọi là các thread xử lý yêu cầu) sẽ chịu trách nhiệm lấy chúng ra và xử lý. Các loại yêu cầu phổ biến nhất từ client là:

Produce requests: Được gửi bởi các producer và chứa các message mà các client gửi đến các broker Kafka.

Fetch requests: Được gửi bởi các consumer và các follower replicas khi họ đọc message từ các broker Kafka.

Admin requests: Được gửi bởi các admin client khi thực hiện các thao tác metadata như tạo và xóa topic.

Cả produce requests và fetch requests bắt buộc phải đượ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 cụ thể và leader của partition này nằm trên một broker khác, client gửi produce requests sẽ nhận được phản hồi lỗi là “Không phải Leader cho partition.”. Lỗi tương tự cũng xảy ra nếu một fetch requests cho một partition cụ thể đến một broker không có leader của partition đó. Các client của Kafka có trách nhiệm gửi các produce requests và fetch requests đến broker chứa leader của partition liên quan đến yêu cầu đó.

3. Làm thế nào mà các client biết gửi yêu cầu đến đâu?

Các client của Kafka sử dụng một loại yêu cầu gọi là yêu cầu metadata (metadata request), trong đó có danh sách các topic mà client quan tâm. Phản hồi từ server sẽ chỉ ra các partition trong các topic, các bản sao cho từng partition, và bản sao nào là leader. Yêu cầu metadata có thể được gửi đến bất kỳ broker nào vì tất cả các broker đều có bộ đệm metadata chứa thông tin này.

Các client thường lưu trữ thông tin này trong bộ nhớ cache và sử dụng để gửi các yêu cầu produce và fetch đến broker chính xác cho từng partition. Các client cũng cần phải thỉnh thoảng refresh thông tin này (thời gian refresh được kiểm soát bởi tham số cấu hình metadata.max.age.ms) bằng cách gửi một yêu cầu metadata khác để kiểm tra xem metadata của topic có thay đổi không — chẳng hạn, nếu một broker mới được thêm vào hoặc một số bản sao được chuyển đến broker mới (Xem Hình 2). Hơn nữa, nếu một client nhận được lỗi “Not a Leader” cho một yêu cầu của nó, client sẽ làm mới metadata của mình trước khi thử gửi lại yêu cầu, vì lỗi này cho thấy client đang sử dụng thông tin lỗi thời và gửi yêu cầu đến broker không chính xác. Hình 2. Định tuyến yêu cầu của client

Bài tiếp theo chúng ta sẽ phân tích chi tiết từng loại yêu cầu phổ biến phía trên.

4. Thông tin kết nối

Nếu anh em muốn trao đổi thêm về bài viết, 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/

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