Điều gì quyết định sự bù đắp của người tiêu dùng Kafka?

Tôi còn khá mới với Kafka. Tôi đã thực hiện một chút thử nghiệm với nó, nhưng một vài điều không rõ ràng đối với tôi về sự bù đắp của người tiêu dùng. Từ những gì tôi đã hiểu cho đến nay, khi một người tiêu dùng bắt đầu, phần bù nó sẽ bắt đầu đọc được xác định bởi cài đặt cấu hình auto.offset.reset(sửa tôi nếu tôi sai).

Bây giờ hãy nói ví dụ rằng có 10 tin nhắn (từ 0 đến 9) trong chủ đề và một người tiêu dùng đã tình cờ tiêu thụ 5 trong số chúng trước khi nó đi xuống (hoặc trước khi tôi giết người tiêu dùng). Sau đó nói tôi khởi động lại quá trình tiêu dùng đó. Câu hỏi của tôi là:

1. Nếu auto.offset.resetđược đặt thành smallest, nó sẽ luôn bắt đầu tiêu thụ từ offset 0?

2. Nếu auto.offset.resetđược đặt thành largest, nó có bắt đầu tiêu thụ từ offset 5 không?

3. Là hành vi liên quan đến loại kịch bản này luôn luôn xác định?

Xin đừng ngần ngại để bình luận nếu bất cứ điều gì trong câu hỏi của tôi không rõ ràng. Cảm ơn trước.

Nó phức tạp hơn một chút so với bạn mô tả.
Các auto.offset.resetđá config trong ONLY nếu nhóm người tiêu dùng của bạn không có một nơi nào đó cam kết bù đắp hợp lệ (2 kho bù đắp được hỗ trợ hiện nay là Kafka và Zookeeper), và nó cũng phụ thuộc vào những gì sắp xếp của người tiêu dùng bạn sử dụng.

Nếu bạn sử dụng một người tiêu dùng java cấp cao thì hãy tưởng tượng các tình huống sau:

1. Bạn có một người tiêu dùng trong một nhóm người tiêu dùng group1đã tiêu thụ 5 tin nhắn và chết. Lần tới khi bạn bắt đầu người tiêu dùng này, nó thậm chí sẽ không sử dụng auto.offset.resetcấu hình đó và sẽ tiếp tục từ nơi nó chết vì nó sẽ chỉ lấy phần bù được lưu trữ từ bộ lưu trữ bù (Kafka hoặc ZK như tôi đã đề cập).

2. Bạn có tin nhắn trong một chủ đề (như bạn mô tả) và bạn bắt đầu một người tiêu dùng trong một nhóm người tiêu dùng mới group2. Không có phần bù được lưu trữ ở bất cứ đâu và lần này, auto.offset.resetcấu hình sẽ quyết định bắt đầu từ đầu chủ đề ( earliest) hay từ cuối chủ đề ( latest)

Một điều nữa ảnh hưởng đến giá trị bù nào sẽ tương ứng earliestvà cấu hình latestlà chính sách lưu giữ nhật ký. Hãy tưởng tượng bạn có một chủ đề với lưu giữ được cấu hình đến 1 giờ. Bạn tạo ra 5 tin nhắn, và sau đó một giờ bạn đăng thêm 5 tin nhắn. Phần latestbù sẽ vẫn giữ nguyên như trong ví dụ trước, nhưng phần bù earliestsẽ không thể là 0do Kafka sẽ xóa các tin nhắn này và do đó phần bù có sẵn sớm nhất sẽ là 5.

Tất cả mọi thứ được đề cập ở trên không liên quan đến SimpleConsumervà mỗi khi bạn chạy nó, nó sẽ quyết định nơi bắt đầu sử dụng auto.offset.resetcấu hình.

Nếu bạn sử dụng phiên bản Kafka cũ hơn 0.9, bạn phải thay thế earliest, latestbằng smallest, largest.

Chỉ là một bản cập nhật: Từ Kafka 0.9 trở lên, Kafka đang sử dụng phiên bản Java mới của người tiêu dùng và tên tham số auto.offset.reset đã thay đổi; Từ hướng dẫn:

Phải làm gì khi không có phần bù ban đầu trong Kafka hoặc nếu phần bù hiện tại không còn tồn tại trên máy chủ nữa (ví dụ: vì dữ liệu đó đã bị xóa):

sớm nhất : tự động đặt lại phần bù thành phần bù sớm nhất

mới nhất : tự động đặt lại phần bù thành phần bù mới nhất

không có : ném ngoại lệ cho người tiêu dùng nếu không tìm thấy phần bù trước đó cho nhóm người tiêu dùng

bất cứ điều gì khác: ném ngoại lệ cho người tiêu dùng.

Tôi đã dành một chút thời gian để tìm thấy điều này sau khi kiểm tra câu trả lời được chấp nhận, vì vậy tôi nghĩ rằng nó có thể hữu ích cho cộng đồng để đăng nó.

Hơn nữa có offsets.retention.minutes. Nếu thời gian kể từ lần cam kết cuối cùng là> offsets.retention.minutes, thì auto.offset.resetcũng khởi động