2015-02-12 7 views
7

Ho impostato un bucket S3 per emettere un evento sull'oggetto PUT su SQS e sto gestendo la coda SQS in un livello di lavoratore EB.SQS invia veramente più record di oggetti S3 PUT per messaggio?

Lo schema per il messaggio che manda SQS è qui: http://docs.aws.amazon.com/AmazonS3/latest/dev/notification-content-structure.html

Records è un array, il che implica che non ci può essere più record inviati in un post al punto finale del mio lavoratore. Questo in realtà accade? O il mio lavoratore riceverà sempre un solo record per messaggio?

L'operatore può restituire solo una risposta, 200 (messaggio gestito correttamente) o non 200 (messaggio non gestito correttamente, che lo rimette in coda), indipendentemente dal numero di record nel messaggio ricevuto.

Quindi, se il mio operatore riceve più record in un messaggio e ne gestisce alcuni con successo (ad esempio facendo qualcosa con effetti collaterali come l'inserimento in un database) ma non riesce su uno o più, come dovrei gestirlo? Se restituisco 200, allora quelli che hanno fallito non saranno riprovati. Ma se restituisco non-200, quindi quelli che sono stati gestiti con successo saranno ritentati inutilmente, e possibilmente reinseriti. Quindi dovrei rendere il mio lavoratore abbastanza intelligente da riprovare solo i falliti - il che è logico che preferirei non dover scrivere.

Questo sarebbe molto più semplice se fosse stato inviato un solo record per messaggio. Quindi se questo è il caso, in pratica, nonostante i record siano un array, mi piacerebbe davvero saperlo!

risposta

7

Per essere chiari, non è il record che "invia SQS". È il record che S3 invia a SQS (oa SNS oa Lambda).

Attualmente, tutte le notifiche di evento S3 hanno un singolo evento per messaggio di notifica. Potremmo includere più record mentre aggiungiamo nuovi tipi di eventi in futuro. Questo è anche un formato di messaggio condiviso con altri servizi AWS e altri servizi possono includere più record.

https://forums.aws.amazon.com/thread.jspa?messageID=592264&#592264

Quindi, per il momento, sembra ci sia un solo record per ogni messaggio.

Ma ... si sta commettendo un errore se si presume che l'applicazione non debba essere preparata a gestire i messaggi ripetuti o duplicati. In qualsiasi sistema massiccio e distribuito come SQS è estremamente difficile garantire che ciò non avvenga mai, comunque improbabile:

Q: Quante volte riceverò ciascun messaggio?

Amazon SQS è progettato per fornire "almeno una volta" la consegna di tutti i messaggi nelle sue code. Sebbene la maggior parte delle volte ogni messaggio venga recapitato all'applicazione esattamente una volta, è necessario progettare il sistema in modo che l'elaborazione di un messaggio più di una volta non crei errori o incongruenze.

http://aws.amazon.com/sqs/faqs/

Per inciso, nella mia piattaforma, più di una voce nella matrice record è considerato un errore, causando il messaggio di essere abbandonata e inviato al dead letter queue per la revisione.

+1

Grazie, è stato utile. Mi piace il tuo approccio per non gestire il caso di record multipli per ora, e apprezzo che tu abbia chiamato "almeno una volta". – sandinmyjoints

+0

_ "In qualsiasi sistema massiccia e distribuito come SQS è estremamente difficile garantire assolutamente che questo non potrà mai accadere" _ - Giusto per chiarire - non è solo 'estremamente difficile', ma impossibile a causa della natura distribuita del servizio. Vedi [this] (http://stackoverflow.com/a/38290017/836214) per alcune informazioni sulla duplicazione. – Krease

+2

@ Krease mio commento era in realtà in riferimento ai vincoli sulla progettazione del servizio stesso - - non i consumatori del servizio. È estremamente difficile progettare un sistema * come * SQS per garantire non duplicazioni, ma non è impossibile ... tuttavia, tale garanzia di coerenza significherebbe un compromesso in termini di disponibilità e/o tolleranza delle partizioni e probabilmente avrà un penalizzazione delle prestazioni a causa di una maggiore comunicazione/coordinamento tra i componenti del servizio. D'altro canto, è impossibile garantire che una consegna duplicata non avverrà mai per un consumatore SQS. –

Problemi correlati