Có thể đảm bảo các thư duy nhất nằm trong hàng đợi thỏmq không?

Question

Về cơ bản người tiêu dùng của tôi cũng là nhà sản xuất. Chúng tôi nhận được một tập dữ liệu ban đầu và nó được gửi đến hàng đợi. Một người tiêu dùng có một mục và xử lý nó, từ thời điểm đó có 3 khả năng:

1. dữ liệu là tốt và được đặt một hàng đợi 'tốt' để lưu trữ
2. dữ liệu là xấu và loại bỏ
3. dữ liệu là không tốt (chưa) hoặc xấu (chưa) để dữ liệu được chia thành các phần nhỏ hơn và được gửi trở lại hàng đợi để xử lý tiếp.

Vấn đề của tôi là với bước 3, vì hàng đợi phát triển rất nhanh, có thể một phần dữ liệu được chia nhỏ thành một phần trùng lặp trong hàng đợi và người tiêu dùng tiếp tục xử lý và kết thúc một vòng lặp vô hạn.

Tôi nghĩ rằng cách ngăn chặn điều này là để ngăn các bản sao xâm nhập vào hàng đợi. Tôi không thể làm điều này ở phía khách hàng bởi vì trong một giờ tôi có thể có nhiều lõi xử lý hàng tỷ điểm dữ liệu (để mỗi khách hàng quét nó trước khi gửi sẽ làm chậm quá nhiều). Tôi nghĩ rằng điều này cần phải được thực hiện ở phía máy chủ nhưng, như tôi đã đề cập, dữ liệu là khá lớn và tôi không biết làm thế nào để đảm bảo hiệu quả không có bản sao.

Tôi có thể đang yêu cầu điều không thể nhưng tôi nghĩ rằng tôi sẽ chụp. bất kì ý kiến ​​nào đều được đánh giá cao.

Answer 1

Vấn đề cốt lõi có vẻ là điều này:

"...its possible that a piece of data is broken down into a part that's 
duplicated in the queue and the consumers continue to process it and 
end up in a infinite loop." 

Bạn có thể tập trung vào tính độc đáo của ảnh đang đợi bạn tất cả các bạn muốn, nhưng vấn đề ở trên là nơi bạn nên tập trung nỗ lực của bạn, IMO. Một cách để ngăn chặn vòng lặp vô hạn có thể là có bit "truy cập" trong tải trọng thư của bạn do người tiêu dùng đặt trước khi họ xếp hàng lại mục bị hỏng.

Một tùy chọn khác sẽ là yêu cầu người tiêu dùng xếp lại hàng đợi đặc biệt được xử lý hơi khác để ngăn chặn vòng lặp vô hạn. Dù bằng cách nào, bạn cũng nên tấn công vấn đề bằng cách xử lý vấn đề này như một phần cốt lõi trong chiến lược của ứng dụng của bạn thay vì sử dụng tính năng của hệ thống nhắn tin để đi xung quanh nó.

Answer 2

Tôi nghĩ rằng ngay cả khi bạn có thể khắc phục vấn đề của không gửi bản sao vào hàng đợi, bạn sẽ sớm hay muộn trúng vấn đề này:

Từ RabbitMQ Tài liệu: "Phục hồi từ thất bại: trong trường hợp một khách hàng bị ngắt kết nối với nhà môi giới do lỗi của nút mà khách hàng đã được kết nối, nếu khách hàng là khách hàng xuất bản, có thể người môi giới đã chấp nhận và chuyển các tin nhắn từ máy khách mà không có khách hàng đã nhận được xác nhận cho họ và tương tự như vậy về phía tiêu thụ, khách hàng có thể đã đưa ra lời cảm ơn cho các thông điệp và không biết liệu những lời cảm ơn đó có thực hiện cho nhà môi giới và được xử lý trước sự thất bại hay không xảy ra. Tóm lại, bạn vẫn cần phải đảm bảo rằng khách hàng tiêu thụ của bạn có thể xác định và xử lý các thông báo trùng lặp. "

Về cơ bản, có vẻ như vậy, bạn gửi yêu cầu đến rabbitmq, rabbitmq trả lời bằng ACK nhưng vì 1 lý do hoặc người khác, người tiêu dùng hoặc nhà sản xuất của bạn không nhận được ACK này. Rabbitmq không có cách nào biết được ack chưa được nhận và nhà sản xuất của bạn sẽ kết thúc việc gửi lại tin nhắn, chưa bao giờ nhận được thông báo.

Thật khó để xử lý các thư trùng lặp, đặc biệt là trong các ứng dụng mà nhắn tin được sử dụng như một loại RPC, nhưng có vẻ như điều này là không tránh khỏi khi sử dụng loại kiến ​​trúc nhắn tin này.