Polling brevi e lunghi di Amazon SQS - Amazon Simple Queue Service

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Polling brevi e lunghi di Amazon SQS

Amazon SQS offre opzioni di polling brevi e lunghe per ricevere messaggi da una coda. Considera i requisiti della tua applicazione in termini di reattività ed efficienza dei costi quando scegli tra queste due opzioni di polling:

  • Sondaggio breve (impostazione predefinita): la ReceiveMessagerichiesta interroga un sottoinsieme di server (in base a una distribuzione casuale ponderata) per trovare i messaggi disponibili e invia una risposta immediata, anche se non viene trovato alcun messaggio.

  • Sondaggio prolungato: ReceiveMessageinterroga tutti i server alla ricerca di messaggi, inviando una risposta una volta che è disponibile almeno un messaggio, fino al massimo specificato. Una risposta vuota viene inviata solo se scade il tempo di attesa per il polling. Questa opzione può ridurre il numero di risposte vuote e potenzialmente ridurre i costi.

Nelle sezioni seguenti vengono illustrati i dettagli del polling breve e del polling lungo.

Utilizzo dei messaggi con lo short polling

Quando consumi messaggi da una coda (FIFO o standard) utilizzando un polling breve, Amazon SQS campiona un sottoinsieme dei suoi server (in base a una distribuzione casuale ponderata) e restituisce messaggi solo da quei server. Pertanto, una determinata richiesta ReceiveMessage potrebbe non restituire tutti i messaggi. Tuttavia, se hai meno di 1.000 messaggi in coda, una richiesta successiva restituirà i tuoi messaggi. Se continui a utilizzare messaggi dalle code, Amazon SQS campiona tutti i propri server e riceverai tutti i messaggi.

Il diagramma qui di seguito mostra il comportamento di short-polling dei messaggi restituiti da una coda standard dopo che uno dei componenti del sistema invia una richiesta di ricezione. Amazon SQS campiona diversi server (in grigio) e restituisce i messaggi A, C, D e B da questi server. Il messaggio E non viene restituito in questa richiesta, ma viene restituito in una richiesta successiva.

Campionamento dei messaggi mediante polling breve (standard)

Utilizzo di messaggi con long polling

Quando il tempo di attesa per l'azione dell'API ReceiveMessage è superiore a 0, viene attivato un polling lungo. Il tempo massimo di attesa per il polling lungo è di 20 secondi. Il long polling aiuta a ridurre il costo di utilizzo di Amazon SQS eliminando il numero di risposte vuote (quando non ci sono messaggi disponibili per una richiesta ReceiveMessage) e le risposte vuote false (quando i messaggi sono disponibili, ma non sono inclusi nella risposta). Per informazioni su come abilitare il polling lungo per una coda nuova o esistente utilizzando la console Amazon SQS, consulta Configurazione dei parametri della coda tramite la console Amazon SQS. Per le best practice, consulta Configurazione di sondaggi lunghi in Amazon SQS.

Il long polling offre i seguenti benefici:

  • Elimina le risposte vuote consentendo a Amazon SQS di attendere fino a che un messaggio non è disponibile nella coda prima di inviare una risposta. A meno che la connessione non scada, la risposta alla richiesta ReceiveMessage contiene almeno uno dei messaggi disponibili, fino al numero massimo di messaggi specificato nell'operazione ReceiveMessage. In rari casi, potresti ricevere risposte vuote anche quando una coda contiene ancora messaggi, specialmente se hai specificato un valore basso per il parametro ReceiveMessageWaitTimeSeconds.

  • Riduci le false risposte vuote interrogando tutti i server Amazon SQS, anziché un sottoinsieme di essi.

  • Restituisci i messaggi non appena diventano disponibili.

Per informazioni su come confermare che una coda è vuota, consulta Conferma che una coda Amazon SQS è vuota.

Differenze tra short e long polling

Lo short polling si verifica quando il parametro WaitTimeSeconds di una richiesta ReceiveMessage è impostato su 0 in uno dei seguenti due modi:

  • La chiamata ReceiveMessage imposta WaitTimeSeconds su 0.

  • La chiamata ReceiveMessage non imposta WaitTimeSeconds e l'attributo coda ReceiveMessageWaitTimeSeconds è impostato su 0.