Come posso impostare abbonati MQTT principali e di failover per una coda lavori con AWS IoT?

Ho un sistema in cui un client (chiamiamolo ClientA) può pubblicare richieste su un particolare argomento MQTT. Il broker, nel caso sia importante, è Amazon Web Services. Poi ho un altro client (chiamiamolo MainSubscriber) che è sempre iscritto allo stesso argomento in modo che possa raccogliere richieste da ClientA e fare un lavoro che, alla fine, si trasforma in un'operazione di database. Il database, nel caso sia importante, è DynamoDB.

Poiché MainSubscriber potrebbe non essere sempre accessibile / online, si desidera che un abbonato di failover sia il backup di failover dell'abbonato principale. L'idea è che se l'abbonato principale non gestisce la richiesta in modo tempestivo, l'abbonato al failover si avvia e fa l'operazione di lavoro / database equivalente. La sfida è che il "lavoro" e la risultante "operazione di database" non devono essere duplicati da abbonati principali e di failover.

Ecco un disegno logico di architettura di sistema per questo sistema.

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

Chiaramente, ci sono alcune sfide con un tale sistema:

1. In che modo il sottoscrittore principale indica al sottoscrittore di failover che sta lavorando alla richiesta?
2. In che modo l'abbonato al failover rileva che l'abbonato principale non ha raccolto la richiesta e deve iniziare a lavorarci?
3. In che modo l'abbonato al failover trattiene quindi l'abbonato principale nel caso in cui improvvisamente ritorni online e raccolga la richiesta?
4. Come gestire i problemi di sincronicità tra abbonati principali e di failover?

Preferirei non dover reinventare la ruota se esiste già una soluzione esistente per un tale schema. Quindi, la mia prima domanda è se c'è già qualcosa là fuori?

In caso contrario, stavo pensando di utilizzare DynamoDB con letture fortemente coerenti per agire come mediatore tra l'abbonato Main e Failover. Quindi, la mia seconda domanda è se ci sono schemi ben stabiliti per farlo?

Secondo la documentazione AWS SQS (come hai detto il broker è AWS) questo dovrebbe essere nativo:

Immediatamente dopo la ricezione, il messaggio rimane nella coda. Per impedire ad altri utenti di elaborare nuovamente il messaggio, Amazon SQS imposta un timeout di visibilità, un periodo di tempo durante il quale Amazon SQS impedisce ad altri componenti di consumo di ricevere ed elaborare il messaggio.

Il problema è trovare il timeout di visibilità corretto in base al tempo di elaborazione massimo.

Hai ancora una piccola possibilità che entrambi gli utenti elaborino lo stesso messaggio, in questo caso il tuo codice abbonato dovrebbe tentare di creare un output idempotente per il database (almeno la stessa chiave primaria) e gestire con grazia un errore quando provi a inserire lo stesso record.

Potresti voler esaminare il concetto di code di lettere morte di AWS SQS . Dai documenti AWS:

Una coda di lettere morte è una coda che altre code (di origine) possono scegliere come target messaggi che non possono essere elaborati (consumati) correttamente. È possibile mettere da parte e isolare questi messaggi nella coda delle lettere morte per determinare perché la loro elaborazione non è riuscita.

Pertanto, se si indica al sottoscrittore principale di ascoltare dalla coda normale e al sottoscrittore secondario di ascoltare dalla coda di messaggi non instradabili, il problema del failover dovrebbe essere risolto.

Inoltre, con questo, vengono risolti 1, 2 e 3 dei tuoi problemi. Gli abbonati principali e secondari non hanno bisogno di parlarsi in questo caso.

Inoltre, basandoti sulla risposta di Tensibai, assicurati che il tuo codice abbonato sia scritto in modo da ricevere un messaggio alla volta se più abbonati stanno ascoltando la stessa coda a causa delvisibility timeout

Il rovescio della medaglia sarebbe che avrebbe introdotto un ritardo nell'elaborazione, i messaggi entrano nella coda delle lettere morte solo dopo un po '.

Quindi, nel caso non lo desiderassi, puoi procedere con la risposta di Tensibai. E se puoi tollerarlo, invece di avere una tabella Dynamo aggiuntiva per i controlli di stato, puoi usarlo.