Prelettura dei messaggi del bus di servizio di Azure
La funzionalità prerecupero recupera i messaggi in background in un buffer locale fino al conteggio dei prerecuperi. I messaggi vengono serviti dal buffer. Come accade, lo spazio viene liberato nel buffer e il ricevitore eseguirà il prerecupero in background.
Per abilitare la funzionalità di Prelettura, impostare il numero di preletture della coda o della sottoscrizione client su un numero maggiore di zero. La configurazione del valore su zero consente di disattivare la prelettura. Se sono presenti messaggi nel buffer di prerecupero dopo la disattivazione della funzionalità, l'applicazione riceve prima tali messaggi dal buffer e quindi passa al servizio.
Impostare la proprietà numero preletture sugli oggetti ServiceBusReceiverOptions e ServiceBusProcessorOptions.
Nota
Java Script SDK non supporta la funzionalità di Prelettura.
Mentre i messaggi sono disponibili nel buffer di Prelettura, tutte le chiamate di ricezione successive vengono soddisfatte immediatamente dal buffer. Il buffer viene rifornito in background man mano che lo spazio diventa disponibile. Se non sono presenti messaggi disponibili per il recapito, l'operazione di ricezione svuota il buffer e quindi attende o si blocca, in base a quanto previsto.
Perché Prelettura non è l'opzione predefinita?
La Prelettura accelera il flusso di messaggi facendo in modo che un messaggio sia immediatamente disponibile per il recupero locale prima che un'applicazione ne richieda uno. Questo vantaggio a livello di velocità effettiva è il risultato di un compromesso che l'autore dell'applicazione deve effettuare in modo esplicito.
Quando si usa la modalità di ricezione ed eliminazione, tutti i messaggi acquisiti nel buffer di Prelettura non sono più disponibili nella coda. I messaggi rimangono solo in memoria nel buffer di Prelettura fino a quando non vengono ricevuti nell'applicazione. Se l'applicazione viene terminata prima della ricezione dei messaggi nell'applicazione, tali messaggi vengono irrimediabilmente persi.
Quando si usa la modalità di ricezione del blocco di visualizzazione, i messaggi recuperati nel buffer di Prelettura vengono acquisiti nel buffer in uno stato bloccato. Il timer di blocco inizia dal momento in cui il messaggio viene prerecuperato nel buffer. Se il buffer di Prelettura è di grandi dimensioni e l'elaborazione richiede una quantità di tempo tale che i blocchi del messaggio scadono durante la permanenza nel buffer di Prelettura o addirittura mentre l'applicazione elabora il messaggio, è possibile che l'applicazione debba gestire alcuni eventi confusi. È possibile che l'applicazione acquisisca un messaggio con un blocco scaduto o con scadenza imminente. In tal caso, l'applicazione potrebbe elaborare il messaggio, ma poi ritrovarsi che non è in grado di completare il messaggio a causa di una scadenza del blocco. L'applicazione può controllare la proprietà LockedUntilUtc, ma tenere presente che l'asimmetria dell'orologio tra il broker e l'orologio del computer locale.
Se il blocco scade automaticamente nel buffer di prelettura, il messaggio viene considerato come abbandonato e viene reso di nuovo disponibile per il recupero dalla coda. Il messaggio verrà quindi recuperato nuovamente nel buffer di prerecupero e posizionato alla fine. Se il buffer di prerecupero non può in genere essere utilizzato durante la scadenza del messaggio, i messaggi vengono prerecuperati ripetutamente ma non recapitati in modo efficace in uno stato utilizzabile (bloccato in modo valido) e vengono infine spostati nella coda dei messaggi non recapitabili dopo il superamento del numero massimo di recapito.
Se un'applicazione abbandona in modo esplicito un messaggio, il messaggio potrebbe essere nuovamente disponibile per il recupero dalla coda. Quando la Prelettura è abilitata, il messaggio viene recuperato nuovamente nel buffer di Prelettura e posizionato alla fine. Poiché i messaggi dal buffer di prerecupero vengono svuotati nell'ordine FIFO (First-In, First Out), l'applicazione potrebbe ricevere messaggi non in ordine. Ad esempio, l'applicazione può ricevere un messaggio con ID 2 e quindi un messaggio con ID 1 (abbandonato in precedenza) dal buffer.
Se è necessario un livello elevato di affidabilità per l'elaborazione di messaggi e se l'elaborazione richiede molto impegno e tempo, è consigliabile usare con cautela la funzionalità di Prelettura o non usarla del tutto. Se è necessaria una velocità effettiva elevata e l'elaborazione dei messaggi è in genere poco costosa, la prelettura offre vantaggi significativi a livello di velocità effettiva.
Il numero massimo di prelettura e la durata del blocco configurati nella coda o nella sottoscrizione devono essere bilanciati in modo che il timeout del blocco sia almeno superiore alla durata cumulativa prevista dell'elaborazione di messaggi per le dimensioni massime del buffer di prelettura, più un messaggio. Allo stesso tempo, la durata del blocco non dovrebbe essere così lunga che i messaggi possono superare il tempo massimo di vita durante il blocco, in quanto ciò significa che vengono rimossi se non possono essere completati quando sono stati prerecuperati.
Il 30 settembre 2026 verranno ritirate le librerie dell'SDK del bus di servizio di Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, che non sono conformi alle linee guida di Azure SDK. Verrà terminato anche il supporto del protocollo SBMP, quindi non sarà più possibile usare questo protocollo dopo il 30 settembre 2026. Eseguire la migrazione alle librerie più recenti di Azure SDK, che offrono aggiornamenti critici della sicurezza e funzionalità migliorate, prima di tale data.
Anche se le librerie precedenti possono ancora essere usate oltre il 30 settembre 2026, non riceveranno più il supporto e gli aggiornamenti ufficiali da Microsoft. Per altre informazioni, vedere l'annuncio del ritiro del supporto.