Jepsen: Kết quả kiểm chứng Bufstream 0.1

Cập nhật_2024-11-13

• Báo cáo ban đầu cho rằng khi bật auto-commit, consumer có thể tự động commit offset được trả về từ lần poll gần nhất, dẫn đến mất dữ liệu.
• Tuy nhiên, nhiều độc giả phản biện rằng trên thực tế consumer auto-commit sẽ commit offset của lần poll trước đó, chứ không phải lần poll gần nhất.
• Kết quả thử nghiệm với Java Kafka client cũng ủng hộ nhận định này, và hành vi có thể khác nhau tùy từng client.
• Các khẳng định cụ thể về auto-commit đã được gỡ khỏi báo cáo, và cần thêm nghiên cứu.

Bối cảnh

• Kafka là một hệ thống streaming phổ biến, cung cấp replication, sharding và append-only log.
• Bufstream là một giải pháp thay thế cho Kafka, ưu tiên quản trị dữ liệu và hiệu quả chi phí trong môi trường đám mây.
• Tương tự Kafka, Bufstream cung cấp tập hợp các log được sắp xếp một phần gọi là topic, và mỗi topic được chia thành các partition.
• Bufstream tương thích với các Kafka client tiêu chuẩn, và được cấu thành từ agent — dịch vụ stateless cung cấp Kafka API, object store lưu trữ dữ liệu, và dịch vụ điều phối.
• Bufstream giảm chi phí bằng cách ghi trực tiếp dữ liệu vào các dịch vụ object storage, và có thể vận hành trên các VM stateless, tự động mở rộng.

Độ an toàn phía client

• Bufstream được thiết kế cho nhiều ứng dụng streaming khác nhau và thiết lập nhiều tùy chọn cấu hình client để đảm bảo vận hành an toàn.
• Giống Kafka, hệ thống dùng mặc định acks = all và đặt enable.auto.commit = false để ngăn mất dữ liệu.
• Sử dụng auto.offset.reset = earliest để consumer có thể quan sát toàn bộ log.

Giao dịch

• Bufstream hỗ trợ hệ thống giao dịch của Kafka, cung cấp một dạng atomicity yếu thông qua cấu hình phức tạp.
• Consumer có thể chạy ở mức cô lập read_uncommitted hoặc read_committed, trong đó read_committed ngăn một số hiện tượng (G1a, G1c).
• G0 vẫn xảy ra trên Kafka, Redpanda và Bufstream, điều này không khớp với mức cô lập được tài liệu hóa.

Thiết kế kiểm thử

• Đã kiểm thử từ Bufstream 0.1.0 đến 0.1.3 bằng thư viện kiểm thử Jepsen và Java Kafka Client.
• Các bài kiểm thử đánh giá độ an toàn của Bufstream bằng cách đưa vào nhiều loại lỗi khác nhau.

Hàng đợi

• Một workload hàng đợi được thiết kế theo mô hình dữ liệu của Kafka và dùng trên Bufstream.
• Mỗi tiến trình logic chạy producer, consumer và client quản trị, đồng thời gửi record cho nhiều key khác nhau.

Hủy bỏ

• Dựa trên các kết quả bất ngờ, một workload được thiết kế để hủy giao dịch và theo dõi offset.
• Offset sau các giao dịch bị hủy được phân thành bốn nhóm: tiến lên, tua lùi, tua lùi thêm, khác.

Kết quả Bufstream

Consumer bị treo (#1)

• Từ 0.1.0 đến 0.1.3-rc.8, đã xảy ra lỗi khiến lệnh gọi consumer.poll() trả về ngay nhưng không trả record nào.
• Bufstream đã khắc phục vấn đề ở 0.1.3-rc.6 bằng cách làm mới cache.

Producer và consumer bị treo (#2)

• Ngay cả ở 0.1.3-rc.6, vẫn có lỗi khiến lệnh gọi InitProducerId hoặc listOffsets thất bại.
• Bufstream đã sửa vấn đề bằng cách bổ sung logic polling.

Offset 0 sai (#3)

• Từ 0.1.0 đến 0.1.3-rc.2, đã xảy ra lỗi gán nhầm offset 0.
• Bufstream đã sửa lỗi này ở 0.1.3-rc.6.

Mất bản ghi ghi giao dịch (#4)

• Ở phiên bản 0.1.2, đã xảy ra lỗi khiến các record thuộc giao dịch đã commit bị biến mất.
• Bufstream đã sửa lỗi ở 0.1.3-rc2.

Mất ghi do lọc phía máy chủ (#5)

• Ở 0.1.3-rc.8, mất ghi xảy ra để phản ứng với các lỗi nhẹ.
• Bufstream đã sửa vấn đề ở 0.1.3-rc.12.

Kết quả Kafka

Thông báo lỗi gây hiểu nhầm (KIP-588)

• ProducerFencedException cũng có thể xảy ra khi timeout giao dịch.
• Nhóm Kafka được khuyến nghị thay đổi thông báo lỗi.

Khả năng chờ vô hạn khi đóng consumer (KAFKA-17734)

• Lệnh gọi Consumer.close() có thể chờ vô hạn trong network IO.
• Vấn đề đang được theo dõi qua KAFKA-17734.

Offset consumer khó dự đoán sau thất bại giao dịch (KAFKA-17582)

• Tài liệu hiện thiếu mô tả về hành vi mong đợi của offset consumer khi giao dịch thất bại.
• Consumer có thể tua lùi offset hoặc tiếp tục tiến lên sau một giao dịch bị hủy.

[GN⁺]

Ý kiến Hacker News

• Trong lúc điều tra các vấn đề xảy ra trong Kafka, người ta phát hiện có các lần ghi không nhìn thấy được. Điều này làm dấy lên khả năng các thông điệp Produce bị trì hoãn bị đưa vào các giao dịch trong tương lai, từ đó vi phạm các đảm bảo của giao dịch. Cũng có nghi ngờ rằng Kafka Java Client có thể tái sử dụng số thứ tự khi yêu cầu bị hết thời gian chờ. Cần thêm nhiều thử nghiệm với Kafka

  • Có lẽ Jepsen nên thực hiện lại một cuộc điều tra chuyên sâu về Kafka. Lần điều tra gần nhất là vào năm 2013, và rất có thể sẽ tìm ra nhiều vấn đề trong chính Kafka. Những lỗi kiểu "xác nhận đã ghi rồi âm thầm loại bỏ" có vẻ cực kỳ nghiêm trọng

• Khi xem trang sản phẩm của Bufstream, có người thắc mắc hai tuyên bố này tương thích với nhau như thế nào

  • Bufstream chạy hoàn toàn bên trong AWS hoặc GCP VPC, nên có thể kiểm soát hoàn toàn dữ liệu, metadata và thời gian hoạt động. Bufstream tuyệt đối không giao tiếp với bên ngoài
  • Giá của Bufstream rất đơn giản: $0.002 cho mỗi GiB chưa nén (khoảng $2 per TiB). Không tính phí theo core, agent hay mỗi lần gọi
  • Có vẻ như họ không thể vận hành toàn bộ hoạt động kinh doanh chỉ dựa trên một hệ thống tin cậy

• Cảm thấy ngạc nhiên về tính năng auto-commit của Kafka

  • Kafka consumer thực sự có thể tự động commit offset bất kể việc xử lý đã hoàn tất hay chưa. Điều này có nghĩa là nếu consumer poll bản ghi rồi commit xong mà sau đó bị crash, bản ghi có thể bị mất
  • Theo tài liệu, khi auto-commit được bật, mỗi lần phương thức poll được gọi, hệ thống sẽ chuẩn bị tự động commit offset của các thông điệp đã được trả về. Nếu việc xử lý thông điệp chưa hoàn tất thì khi crash có nguy cơ mất tiến trình xử lý thông điệp
  • Việc điều chỉnh khoảng thời gian auto-commit có thể giúp giảm xử lý trùng lặp, nhưng không giúp tránh mất thông điệp

• Giao thức transaction của Kafka có vấn đề ở mức nền tảng và cần phải được sửa

  • Công tác điều tra và bài viết đều rất xuất sắc

• Có người tò mò liệu Kyle đã xem xét NATS Jetstream chưa

• Không tìm thấy dự án GitHub của bufstream. Tò mò không biết có manh mối nào không

• Sau khi đọc các bài blog và tài liệu liên quan, có vẻ Kafka định nghĩa "exactly once delivery" là một thuộc tính của thao tác "đọc-xử lý-ghi". Có lẽ mô tả nó như một transaction sẽ phù hợp hơn

• Cụm từ "có thể quan sát một phần hoặc toàn bộ transaction" có lẽ nên được hiểu là "consumer có thể quan sát một phần hoặc toàn bộ"

• Tò mò không biết phần mềm này được dùng để làm gì. Phục vụ observability? Hộp đen?