Các ứng dụng tương tác với Kafka như thế nào?
Khi mình tìm hiểu cách các ứng dụng (gọi là client) tương tác với Kafka như thế nào thì mình đi trả lời các câu hỏi sau:
- Như thế nào?
- Bằng cách nào?
- Hoạt động ra sao?
Như thế nào?
Client giao tiếp với Kafka thông qua Kafka broker. Hầu hết các Kafka broker sẽ xử lý các yêu cầu (request) từ client gửi đến partition leader, partition replica và controller.
Bằng cách nào?
Kafka sử dụng một giao thức binary (thông qua TCP) để định dạng nội dung gửi qua lại giữa broker và client hoặc giữa các broker.
Tất cả các request đều có header chuẩn bao gồm:
- Request type (còn được gọi là API key)
- Request version
- Correlation ID
- Client ID
Chi tiết hơn về protocol này chúng ta có thể tìm hiểu ở đây: http://kafka.apache.org/protocol.html
Hoạt động ra sao?
Khi các yêu cầu (request) được đặt trên hàng đợi yêu cầu (request queue), các luồng IO (còn được gọi là các luồng xử lý yêu cầu) có trách nhiệm chọn và xử lý chúng. Các loại yêu cầu từ client phổ biến nhất là:
- Produce requests: Gửi bởi producer (là một loại client) gửi message đến Kafka broker.
- Fetch requests: Gửi bởi consumer (là một loại client) hoặc follower replica (là một bản replica của partition trên một broker khác broker chứa leader replica) khi đọc message từ broker.
- Admin requests: Gửi bởi Admin client khi thực hiện các thao tác với metadata như tạo và xóa topic,..
Producer & fetch request đều phải được gửi đến broker mà trên đó có leader replica của partition được yêu cầu. Nếu request đến broker không chứa leader replica của partition đó sẽ báo lỗi “Not a Leader for Partition.”
Client chịu trách nhiệm gửi các producer & fetch request đến đúng broker chứa leader replica của partition được yêu cầu.
Vậy làm thế nào để client gửi request đến đúng broker?
Client sử dụng metadata request với topic liên quan, khi đó broker sẽ trả về các thông tin như partition của topic đó, replica của partition và replica nào là leader.
Metadata request có thể gửi đến bất kỳ broker nào vì tất cả broker đều có metadata.
Khi nhận metadata từ broker, client sẽ lưu lại vào cache và sử dụng ở các request tiếp theo. Client sẽ refresh lại metadata, thông số này cấu hình bởi metadata.max.age.ms.
Producer requests
Tham số acks là dùng để cấu hình số lượng broker cần xác nhận việc nhận message trước khi nó được ghi nhận là ghi thành công. Producer nhận thông báo “written successfully” khi
- acks = 1: message được chấp nhận duy nhất bởi leader
- acks = all: tất cả in-sync replica phải ghi nhận message
- acks = 0: không cần broker xác nhận khi tại thời điểm gửi message
Khi broker chứa leader replica nhận message từ client, nó sẽ thực hiện các bước xác thực:
- client có được quyền produce vào topic này không?
- acks gửi lên có đúng không? (acks phải là 0, 1 hoặc all)
- Nếu acks = all, kiểm tra xem các in-sync replica có thể nhận message không? (có thể broker full disk hoặc lỗi,...)
Sau đó sẽ ghi các message mới vào local disk.
Sau khi message được ghi nhận bởi leader replica, broker sẽ kiểm tra acks, nếu acks = 0 hoặc acks = 1, broker sẽ phản hồi lại cho client ngay lập tức. Nếu acks = all, request đó sẽ được lưu lại vào purgatory cho đến khi nào các in-sync replica có được bản sao của message, sau đó sẽ phản hồi lại client.
Fetch Requests
Broker xử lý fetch request đơn giản hơn produce request. Client gọi request yêu cầu broker gửi message từ topic hoặc partition hoặc offset nào đó. Client có thể giới hạn độ lớn của data trả về từ broker để tránh bị tràn bộ nhớ.
Ngoài việc client có thể đặt giới hạn độ lớn của data trả về thì client có thể đặt mức tối thiểu độ lớn của data trả về. Khi chưa đủ data thì broker sẽ chờ cho đến khi đủ rồi gửi cho client. Việc chờ này sẽ làm giảm chi phí gọi từ client. Client cũng có thể set thời gian chờ tối đa, nếu hết thời gian thì broker sẽ gửi những gì đang có chứ không cần chờ đủ.
Một điểm thú vị là không phải client có thể consume tất cả message có trên leader replica. Hầu hết client chỉ có thể đọc message có đầy đủ trên in-sync replica. Lý do là các message chưa được replica đầy đủ thì sẽ không an toàn — vì nếu leader replica gặp sự cố, một replica khác thay chỗ thì message sẽ không tồn tại trong Kafka. Vì vậy broker chỉ cho phép client đọc message tồn tại trên leader.
Các loại request khác
Ở trên chúng ta thảo luận về 3 loại request phổ biến nhất là Metadata, Produce, Fetch. Ngoài ra Kafka có tới 67 loại request khác nhau.
Recap
- Kafka sử dụng protocol riêng để giao tiếp, truyền dữ liệu với client.
- Kafka có nhiều loại request khác nhau tương ứng với các yêu cầu từ client.
- Client chỉ thao tác dữ liệu với client trên broker có leader replica.
- Client có thể giới hạn các dữ liệu nhận về.
