Làm cách nào tôi có thể thiết lập các thuê bao MQTT chính và chuyển đổi dự phòng cho hàng đợi công việc với AWS IoT?

Tôi có một hệ thống trong đó một khách hàng (hãy gọi nó là ClientA) có thể xuất bản các yêu cầu đến một chủ đề MQTT cụ thể. Nhà môi giới, trong trường hợp có vấn đề, là Amazon Web Services. Sau đó, tôi có một khách hàng khác (hãy gọi nó là MainSubscacker) luôn đăng ký cùng một chủ đề để nó có thể nhận các yêu cầu từ ClientA và thực hiện một số công việc cuối cùng chuyển thành hoạt động cơ sở dữ liệu. Cơ sở dữ liệu, trong trường hợp có vấn đề, là DynamoDB.

Vì MainSubscacker có thể không phải lúc nào cũng có thể truy cập / trực tuyến, nên có mong muốn có một thuê bao chuyển đổi dự phòng để trở thành bản sao lưu dự phòng của thuê bao chính. Ý tưởng là nếu thuê bao chính không xử lý yêu cầu kịp thời, thì thuê bao chuyển đổi dự phòng sẽ khởi động và thực hiện thao tác cơ sở dữ liệu / công việc tương đương. Thách thức là "công việc" và "hoạt động cơ sở dữ liệu" kết quả không được trùng lặp bởi cả thuê bao chính và thuê bao chuyển đổi dự phòng.

Đây là bản vẽ kiến ​​trúc hệ thống logic cho hệ thống này.

                   -----> MainSubscriber ----
                  /                          \
ClientA --> Broker                            ---> Database
                  \                          /
                   ---> FailoverSubscriber --

Rõ ràng, có một số thách thức với một hệ thống như vậy:

1. Làm thế nào để thuê bao chính chỉ ra cho thuê bao failover rằng nó đang làm việc theo yêu cầu?
2. Làm thế nào để thuê bao failover phát hiện ra rằng thuê bao chính đã không nhận được yêu cầu và cần phải bắt đầu làm việc với nó?
3. Làm thế nào để người đăng ký failover giữ người đăng ký chính trong trường hợp bất ngờ quay trở lại trực tuyến và nhận yêu cầu?
4. Làm thế nào để đối phó với các vấn đề đồng bộ giữa các thuê bao chính và chuyển đổi dự phòng?

Tôi thà không phải phát minh lại bánh xe nếu một giải pháp hiện có đã tồn tại cho sơ đồ như vậy. Vì vậy, câu hỏi đầu tiên của tôi là liệu đã có một cái gì đó ngoài kia chưa?

Nếu không, thì tôi đã nghĩ đến việc sử dụng DynamoDB với các lần đọc mạnh mẽ nhất quán để đóng vai trò trung gian hòa giải giữa thuê bao chính và người chuyển đổi dự phòng. Vì vậy, câu hỏi thứ hai của tôi là liệu có bất kỳ kế hoạch được thiết lập tốt để làm điều này?

Theo Tài liệu SQS AWS (như bạn đã nói nhà môi giới là AWS), đây phải là nguồn gốc:

Ngay sau khi nhận được tin nhắn, nó vẫn nằm trong hàng đợi. Để ngăn người tiêu dùng khác xử lý lại tin nhắn, Amazon SQS đặt thời gian chờ hiển thị, một khoảng thời gian trong đó Amazon SQS ngăn các thành phần tiêu thụ khác nhận và xử lý tin nhắn.

Vấn đề là tìm thời gian chờ hiển thị phù hợp theo thời gian xử lý tối đa của bạn.

Bạn vẫn có một cơ hội nhỏ cả hai thuê bao xử lý cùng một tin nhắn, trong trường hợp này, mã thuê bao của bạn nên cố gắng tạo đầu ra tạm thời cho cơ sở dữ liệu (ít nhất là cùng khóa chính) và sẽ xử lý một cách thất bại khi cố gắng chèn cùng một bản ghi.

Bạn có thể muốn xem xét khái niệm hàng đợi thư chết của AWS SQS . Từ các tài liệu AWS:

Hàng đợi thư chết là hàng đợi mà các hàng đợi (nguồn) khác có thể nhắm mục tiêu cho các thư không thể được xử lý (tiêu thụ) thành công. Bạn có thể đặt sang một bên và cô lập các tin nhắn này trong hàng đợi thư chết để xác định lý do tại sao quá trình xử lý của chúng không thành công.

Vì vậy, nếu bạn chỉ ra thuê bao chính lắng nghe hàng đợi thông thường và thuê bao phụ nghe từ hàng đợi thư chết, vấn đề chuyển đổi dự phòng sẽ được giải quyết.

Ngoài ra, với điều này, 1, 2 và 3 vấn đề của bạn được quan tâm. Các thuê bao chính và phụ không cần nói chuyện với nhau trong trường hợp này.

Ngoài ra, dựa trên câu trả lời của Tensibai, hãy đảm bảo mã thuê bao của bạn được viết để nhận được một tin nhắn tại một thời điểm nếu nhiều người đăng ký đang nghe cùng một hàng đợi dovisibility timeout

Nhược điểm là nó sẽ giới thiệu một sự chậm trễ trong quá trình xử lý, tin nhắn vào hàng thư chết chỉ sau một thời gian.

Vì vậy, trong trường hợp bạn không muốn điều đó, thì bạn có thể tiếp tục với câu trả lời của Tensibai. Và nếu bạn có thể chịu đựng điều đó, thay vì có thêm một bảng Động để kiểm tra trạng thái, thì bạn có thể sử dụng bảng này.