Call me maybe: Kafka

Bài tóm tắt Jepsen 2013 3. Quy mô lớn Độ khó: Khó

Jepsen · 2013 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bài thời kỳ đầu của Jepsen (Kyle Kingsbury, blog cá nhân), test bản thiết kế replication sắp ra của Kafka 0.8, chưa phải bản phát hành.

Bối cảnh

  • Kafka 0.8 thêm replication: mỗi partition một leader (bầu qua ZooKeeper) giữ ISR (in-sync replica); ghi commit khi mọi node trong ISR ack. LinkedIn tuyên bố chịu được f−1 lỗi với f node vì theo kinh nghiệm vận hành của họ quorum đa số không đủ tin cậy.

Thay đổi chính (kết quả)

  • Để chịu f−1 lỗi, ISR được co về chỉ còn leader; leader khi đó ack ghi chỉ có trên chính nó. Nếu leader mất claim ZooKeeper, Kafka bầu node còn lại bất kỳ, có thể tụt xa, và ghi khác nhánh của leader cũ bị bỏ.
  • Test với request.required.acks=-1, chế độ sync: cô lập leader khỏi follower bằng iptables (ISR co lại, ghi tiếp tục), rồi cô lập hẳn: 987/1.000 ghi được ack nhưng 520 ghi đã ack bị mất, tức mọi ghi trong lúc partition.
  • Lập luận theo Peleg và Wool: với xác suất lỗi mỗi node dưới 1/2, quorum đa số cho availability tối ưu; co ISR về 1 là phía tệ nhất.
  • Hai khuyến nghị gửi đội Kafka: không cho ISR xuống dưới N/2; ISR rỗng thì chặn và báo động thay vì âm thầm bỏ dữ liệu (có thể cấu hình).

Vì sao

  • Kafka đổi an toàn lấy availability khi thiếu node; mặc định thời đó còn ack trước khi replicate.

Bài học cho SWE

  • "Chịu f−1 lỗi" thường có nghĩa là có lúc chỉ một bản giữ dữ liệu đã ack.
  • Hệ sắp vi phạm bất biến nên dừng và gọi người thay vì tự quyết bỏ dữ liệu.

Liên quan