如何通过AWS IoT为作业队列设置主要和故障转移MQTT订阅者？

我有一个系统，客户机（我们称其为ClientA）可以将请求发布到特定的MQTT主题。代理（如果需要的话）是Amazon Web Services。然后，我有另一个客户端（我们称其为MainSubscriber），该客户端始终订阅相同的主题，以便它可以接收来自ClientA的请求并进行某些工作，最后将其转换为数据库操作。如果需要的话，数据库是DynamoDB。

由于MainSubscriber可能不总是可访问/在线的，因此希望有一个故障转移订户作为主订户的故障转移备份。这样的想法是，如果主用户未及时处理请求，则故障转移用户将加入并进行等效的工作/数据库操作。挑战在于，主订户和故障转移订户都不能复制“工作”和所得的“数据库操作”。

这是此系统的逻辑系统架构图。

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

显然，这种系统存在一些挑战：

1. 主订户如何向故障转移订户指示它正在处理请求？
2. 故障转移订户如何检测到主订户尚未接听请求并需要开始处理该请求？
3. 如果故障转移订阅者突然回到联机状态并接收请求，那么该如何转移主订阅者呢？
4. 如何处理主订户与故障转移订户之间的同步性问题？

如果这样的方案已经存在一个解决方案，我宁愿不必重新发明轮子。所以，我的第一个问题是是否已经有东西了？

如果不是，那么我正在考虑使用具有强烈一致性读取的DynamoDB作为Main和Failover订户之间的中介。所以，我的第二个问题是，是否有完善的方案来做到这一点？

根据AWS SQS文档（正如您所说的经纪人是AWS），这应该是本机的：

收到消息后，消息立即保留在队列中。为防止其他使用者再次处理该消息，Amazon SQS设置了可见性超时，在这段时间内Amazon SQS阻止其他使用组件接收和处理消息。

问题是根据您的最大处理时间找到合适的可见性超时。

您仍然很少有机会两个订户都处理相同的消息，在这种情况下，您的订户代码应尝试为数据库创建幂等输出（至少是相同的主键），并且在尝试插入相同记录时应适当地处理失败。

您可能想看看AWS SQS的死信队列的概念。从AWS文档中：

死信队列是其他（源）队列可以针对无法成功处理（消耗）的邮件的队列。您可以搁置这些消息并将它们隔离在死信队列中，以确定为什么无法成功处理它们。

因此，如果将主订户指向普通队列，而副订户则指向死信队列，则应该解决故障转移问题。

此外，借助此功能，您可以解决1、2和3个问题。在这种情况下，主要订户和次要订户不需要互相交谈。

另外，根据Tensibai的答案，请确保您的订户代码已编写，以便在由于以下原因导致多个订户正在侦听同一队列时，一次接收一条消息。visibility timeout

缺点是会导致处理延迟，消息仅在一段时间后才进入死信队列。

因此，如果您不希望这样做，那么可以继续进行Tensibai的回答。而且，如果您可以忍受这一点，则可以使用此表，而不必使用额外的Dynamo表进行状态检查。