Ack (viết tắt của acknowledgment) trong Kafka Producer là cấu hình xác định mức độ đảm bảo về việc phân phối message đến Kafka brokers. Cấu hình này ảnh hưởng đến độ bền dữ liệu và hiệu suất của ứng dụng Kafka.
Có ba loại ack chính:
0: Không có xác nhận (No acknowledgment). Ở mức độ này, producer sẽ gửi tin nhắn đến broker mà không chờ phản hồi. Đây là mức độ ack nhanh nhất nhưng cũng ít đảm bảo nhất vì không có gì đảm bảo tin nhắn đã được broker nhận thành công.
1: Xác nhận leader (Leader acknowledgment). Ở mức độ này, producer sẽ chờ xác nhận từ leader replica trước khi trả về. Leader replica là bản sao dữ liệu chính của một phân vùng Kafka. Mức độ ack này đảm bảo rằng tin nhắn đã được ghi vào leader replica thành công, nhưng không đảm bảo rằng tin nhắn sẽ được sao chép sang tất cả các follower replica.
All: Xác nhận tất cả (All acknowledgment). Ở mức độ này, producer sẽ chờ xác nhận từ tất cả các in-sync replica trước khi trả về. In-sync replica là những bản sao dữ liệu đã được cập nhật đồng bộ với leader replica. Mức độ ack này đảm bảo rằng tin nhắn đã được ghi vào tất cả các bản sao đang hoạt động của một phân vùng Kafka, mang lại độ bền dữ liệu cao nhất nhưng cũng có hiệu suất chậm nhất.
Lựa chọn mức độ ack phù hợp:
Lựa chọn mức độ ack phù hợp phụ thuộc vào nhu cầu cụ thể của ứng dụng.
Nếu hiệu suất là ưu tiên hàng đầu, bạn có thể sử dụng ack level 0. Tuy nhiên, cần lưu ý rằng mức độ ack này không đảm bảo độ bền dữ liệu và có thể dẫn đến mất dữ liệu trong trường hợp broker bị lỗi.
Nếu độ bền dữ liệu quan trọng hơn hiệu suất, bạn nên sử dụng ack level 1 hoặc all. Mức độ ack level 1 cung cấp sự cân bằng tốt giữa hiệu suất và độ bền dữ liệu, trong khi ack level all mang lại độ bền dữ liệu cao nhất nhưng có hiệu suất chậm nhất.
Ngoài ra, bạn cũng cần cân nhắc các yếu tố sau khi lựa chọn mức độ ack:
Kích thước tin nhắn: Tin nhắn lớn thường mất nhiều thời gian để truyền tải và xử lý hơn, do đó có thể ảnh hưởng đến hiệu suất của ack level all.
Tốc độ ghi dữ liệu: Nếu tốc độ ghi dữ liệu cao, việc sử dụng ack level all có thể dẫn đến tắc nghẽn do producer phải chờ xác nhận từ tất cả các in-sync replica.
Mức độ tin cậy của hệ thống: Nếu hệ thống có độ tin cậy cao, bạn có thể sử dụng ack level 0 hoặc 1 để tăng hiệu suất. Tuy nhiên, nếu hệ thống có độ tin cậy thấp, bạn nên sử dụng ack level all để đảm bảo độ bền dữ liệu.
Vai trò của min.insync.replicas:
Cài đặt
min.insync.replicasxác định số bản sao đồng bộ tối thiểu cần có để ghi dữ liệu an toàn vào một phân vùng Kafka.Bản sao leader (bản sao chính) sẽ kiểm tra xem có đủ số bản sao đồng bộ (in-sync replicas) theo yêu cầu của
min.insync.replicashay không trước khi ghi tin nhắn.Dữ liệu được ghi vào leader replica và các bản sao đồng bộ khác. Quá trình ghi có thể được trì hoãn tạm thời nếu chưa đủ bản sao đồng bộ.
Khi các bản sao đồng bộ hoàn tất việc sao chép tin nhắn, leader replica sẽ gửi xác nhận thành công đến producer.
Cấu hình min.insync.replicas:
min.insync.replicascó thể được cấu hình ở cả cấp chủ đề (topic) và cấp broker.Dữ liệu được coi là đã commit (xác nhận thành công) khi nó được ghi vào tất cả các bản sao đồng bộ theo yêu cầu của
min.insync.replicas.Ví dụ: Nếu
min.insync.replicasđược đặt thành 2, thì ít nhất 2 bản sao đồng bộ (bao gồm cả leader) phải xác nhận nhận được dữ liệu thì mới ghi thành công.
Ảnh hưởng của min.insync.replicas:
Cài đặt
min.insync.replicascao hơn 1 giúp đảm bảo dữ liệu được ghi vào nhiều bản sao, tăng độ bền dữ liệu.Tuy nhiên, cài đặt cao hơn cũng có thể ảnh hưởng đến hiệu suất:
Producer có thể phải chờ đợi xác nhận từ nhiều bản sao hơn, làm chậm quá trình gửi tin nhắn.
Nếu số lượng bản sao đồng bộ không đủ theo yêu cầu
min.insync.replicas, broker sẽ từ chối yêu cầu ghi dữ liệu từ producer.
Độ bền dữ liệu (Data Durability):
Với một Topic có hệ số nhân bản (replication factor) là 3, dữ liệu của Topic có thể chịu đựng được việc mất tới 2 broker.
Theo quy tắc tổng quát, với hệ số nhân bản là N, bạn có thể mất tối đa N-1 broker vĩnh viễn mà vẫn khôi phục được dữ liệu.
Tính sẵn sàng (Availability):
Tính sẵn sàng phức tạp hơn một chút... Chúng ta sẽ lấy ví dụ với hệ số nhân bản là 3:
Đọc dữ liệu (Reads): Chỉ cần một phân vùng hoạt động và được coi là ISR (In-Sync Replica - bản sao đồng bộ), Topic sẽ khả dụng để đọc.
Ghi dữ liệu (Writes):
acks=0 & acks=1: Chỉ cần một phân vùng hoạt động và được coi là ISR, Topic sẽ khả dụng để ghi.
acks=all:
min.insync.replicas=1 (mặc định): Topic phải có ít nhất 1 phân vùng hoạt động như ISR (bao gồm cả reader), do đó, hệ thống có thể chịu đựng được việc 2 broker bị lỗi.
min.insync.replicas=2: Topic phải có ít nhất 2 ISR hoạt động, do đó, hệ thống chỉ chịu đựng được tối đa 1 broker bị lỗi (trong trường hợp hệ số nhân bản là 3). Ngoài ra, với thiết lập này, mỗi lần ghi dữ liệu sẽ được ghi ít nhất hai lần.
min.insync.replicas=3: Với hệ số nhân bản là 3, thiết lập này không hợp lý vì hệ thống không thể chịu đựng được bất kỳ broker nào bị lỗi.
Khi sử dụng acks=all với replication.factor=N và min.insync.replicas=M, chúng ta có thể chịu đựng được việc N-M broker bị lỗi để đảm bảo tính sẵn sàng của Topic