Làm cách nào để đảm bảo phân phối công bằng các thông điệp SQS trong cài đặt hệ thống phân tán?

Tôi có nhiều máy chủ, mỗi máy chủ có một tập lệnh bỏ phiếu hàng đợi SQS [tất cả bỏ phiếu trong cùng một hàng đợi].

Vì vậy, có cách nào tôi có thể đảm bảo phân phối tin nhắn công bằng cho tất cả các khách hàng đó không [ví dụ: máy chủ worker của tôi ở đây]. Ví dụ như, nếu có 100 tin nhắn trong hàng đợi, thì 20-20-20-20-20nếu có 5 công nhân, v.v.

AWS ELB (Bộ cân bằng tải đàn hồi) có thể giúp tôi làm điều đó không? Nếu có thì làm thế nào? Nếu không, thì có một dịch vụ thay thế trong hệ sinh thái AWS có thể giúp tôi làm điều đó không?

Hay tôi đang lật đổ điều này? Ý tôi là, điều này có thể được giải quyết một cách đơn giản trong kịch bản bỏ phiếu không? [Xin lưu ý các điều kiện cuộc đua liên quan do nhiều khách hàng bỏ phiếu trong một hàng đợi]

Nếu có 100 tin nhắn trong hàng đợi và 5 người tiêu dùng, phân phối ban đầu sẽ không quá 10-10-10-10-10.

Một phản hồi không bao giờ có thể trả lại hơn 10 tin nhắn .

Điều này có vẻ như không phải là một vấn đề.

Điều kiện chủng tộc liên quan đến nhiều người tiêu dùng cũng không phải là vấn đề. SQS được thiết kế cho nhiều người tiêu dùng đồng thời.

Sử dụng các cuộc thăm dò dài và một bộ đếm thời gian chờ tối đa 20 giây và ngạc nhiên. (Không, chờ 20 giây không làm chậm tin nhắn trong 20 giây. Nó hoàn toàn không trì hoãn chúng. Bạn cần phải xem nó trong thực tế để thực sự hiểu cách thức hoạt động của nó.)

Bạn chắc chắn đang xem xét một số điều, tôi nghi ngờ.

Kiến trúc tốt trong cách bạn sử dụng hàng đợi SQS sẽ giải quyết vấn đề của bạn. Nếu chúng tôi giả sử có 3 phút xử lý mỗi tin nhắn, thì bạn gần như có thể đảm bảo phân phối các tin nhắn bằng nhau vì nó rất lớn so với thời gian cần thiết để thăm dò hàng đợi, nếu bạn chỉ xóa tin nhắn khỏi hàng đợi nó đã được xử lý

Xin lưu ý rằng có giới hạn Thời gian hiển thị 12 giờ đối với bất kỳ thông báo SQS nào, vì vậy nếu bạn không xóa nó trước đó, nó sẽ xuất hiện lại trên hàng đợi. Tôi nghi ngờ đây có lẽ không phải là một giới hạn cho bạn, nhưng hãy ghi nhớ nó.

Bỏ phiếu dài luôn có lợi vì nó mang lại hiệu suất cao hơn với chi phí giảm cho phần lớn các trường hợp sử dụng. Thật không may, bạn không thể kiểm soát số lượng tin nhắn mà mỗi nhân viên nhận được từ hàng đợi do tính chất phân tán của hàng đợi. Nhưng có một số cách giải quyết phía khách hàng có thể giúp bạn cân bằng tải cho công nhân.

Vì vậy, đây là những gì chúng tôi đã làm như một cách giải quyết cho điều này:

Là một trong những giải pháp thay thế, tập lệnh pug có thể kiểm soát số lượng tin nhắn mà mỗi nhân viên nhận được. Có thể đặt ngưỡng cho số lượng tin nhắn tối đa mà mỗi nhân viên có thể xử lý. Ngưỡng này có thể là một giá trị động và có thể sẽ được ApproximateNumberOfMessagesVisiblechia cho số lượng tập lệnh bỏ phiếu / pug. Sau đó, bạn có thể giữ thời gian chờ hiển thị ở bất kỳ giá trị nào thấp hơn để nếu tất cả các tập lệnh pug đang bỏ phiếu dài cùng một lúc, một trong những người bỏ phiếu lấy thông báo, quyết định nó bị quá tải dựa trên ngưỡng, không xóa tin nhắn, tin nhắn quay trở lại hàng đợi và nó có thể bị bắt bởi những người bỏ phiếu khác vẫn có khả năng lấy thông điệp. Tham số ngưỡng có thể được điều chỉnh tốt để đáp ứng nhu cầu của ứng dụng.

Ngoài ra, có cơ chế chuyển đổi dự phòng cũng sẽ giúp, giống như cách các câu trả lời trong bài này mô tả . Tuy nhiên, tôi không đủ khả năng để có hàng đợi chuyển đổi dự phòng trong một kiến ​​trúc phân tán, vì nó sẽ làm tăng sự phức tạp. Vì vậy, cách giải quyết trên là một ý tưởng tốt hơn cho nhóm của tôi.