Consegna push dei messaggi e retry con argomenti dello spazio dei nomi
La consegna push degli spazi dei nomi di Griglia di eventi offre un recapito durable. Griglia di eventi tenta di recapitare ogni messaggio almeno una volta, immediatamente, per ogni sottoscrizione corrispondente. Se l'endpoint di un sottoscrittore non conferma la ricezione di un evento o se si verifica un errore, Griglia di eventi tenta di nuovo il recapito in base a una pianificazione di retry fissa e a criteri di ripetizione. Per impostazione predefinita, Griglia di eventi recapita al sottoscrittore un evento alla volta.
Nota
Poiché Griglia di eventi non garantisce l'ordine per il recapito degli eventi, è possibile che i sottoscrittori non li ricevano in ordine.
Sottoscrizione evento
Una sottoscrizione di eventi è una risorsa di configurazione associata a un singolo argomento di spazio dei nomi. Tra le altre cose, una sottoscrizione di eventi viene usata per impostare i criteri di selezione degli eventi, al fine di definire la raccolta di eventi disponibile per un sottoscrittore del set totale di eventi disponibili in un argomento. Se si sottoscrizione di eventi, viene definito anche l'endpoint di destinazione a cui vengono inviati gli eventi. Inoltre, una sottoscrizione di eventi consente di impostare altre proprietà, ad esempio il numero massimo dei retry di consegna e la durata degli eventi, che definiscono il comportamento di runtime del recapito dell'evento.
Pianificazione delle ripetizioni
Se Griglia di eventi riceve un errore per un tentativo di recapito di eventi, Griglia di eventi decide, in base al tipo di errore, se deve eseguire il retry del recapito.
Se l'errore restituito dall'endpoint sottoscritto è correlato alla configurazione e non può essere corretto con i retry, Griglia di eventi invia l'evento a una destinazione di messaggi non recapitabili configurata. Se non è configurata l’impostazione non recapitabile, l'evento viene eliminato. Ad esempio, un evento è inserito come non recapitabile o viene eliminato quando non è possibile raggiungere l'endpoint configurato nella sottoscrizione di eventi perché è stato eliminato. Il retry di recapito non si verifica per le condizioni e gli errori seguenti:
Condizioni:
ArgumentException
TimeoutException
UnauthorizedAccessException
OperationCanceledException
SocketException
|
Codici di errore
404 - NotFound
401 - Unauthorized
403 - Forbidden
400 -BadRequest
414 RequestUriTooLong
Nota
Se per un endpoint non sono stati configurati i messaggi non recapitabili, gli eventi saranno eliminati al verificarsi degli errori o delle condizioni precedenti. Se si preferisce evitare questi tipi di eventi, è consigliabile configurare messaggi non recapitabili nella sottoscrizione di eventi. Gli eventi non recapitabili saranno eliminati se non viene trovata la destinazione per i messaggi non recapitabili.
Se la condizione o l'errore restituito dall'endpoint sottoscritto non rientra tra quelli negli elenchi precedenti, Griglia di eventi ritenta su una base di lavoro richiesto, usando la pianificazione di ripetizione dei retry di backoff esponenziale seguente:
- 0 secondi (retry immediato)
- 10 secondi
- 30 secondi
- 1 minuto
- 5 minuti
Dopo 5 minuti, Griglia di eventi continua il retry ogni 5 minuti, finché l'evento non è recapitato o sia stato raggiunto il numero massimo di retry o la durata dell'evento.
Criteri di ripetizione
È possibile personalizzare i criteri di ripetizione usando le seguenti due proprietà di configurazione della sottoscrizione di eventi. Se una delle proprietà raggiunge il limite configurato, l’evento viene eliminato (non è stata configurata l’opzione non recapitabili) o viene inserito come non recapitabile.
- Numero massimo di recapito: il valore deve essere un numero intero compreso tra 1 e 10. Il valore predefinito è 10. Per la consegna push, questa proprietà definisce il numero massimo di tentativi di recapito.
- Conservazione dati: questa proprietà è nota anche come
event time to live
. Il valore deve essere un valore di durata ISO 8601 con precisione al minuto. A partire dal momento di pubblicazione dell’evento, questa proprietà definisce l'intervallo di tempo dopo il quale il messaggio scade. Il valore minimo consentito è "PT1M
" (1 minuto). Il valore massimo consentito è 7 giorni o il tempo di conservazione dei dati dell'argomento sottostante, a seconda di quale sia il valore basso. Il portale di Azure offre un'esperienza utente semplice, che consente di indicare i giorni, le ore e i minuti come numeri interi.
Nota
Se si impostano sia Retention
che Maximum delivery count
, Griglia di eventi li usa per determinare quando arrestare il recapito degli eventi. Uno o l’altro arresta il recapito degli eventi. Ad esempio, se conservazione dei dati è impostata su 20 minuti e numero massimo di tentativi di recapito su 10, significa che se un evento non viene recapitato dopo 20 minuti o dopo 10 tentativi, a seconda della condizione che si verifica per prima, l'evento viene inserito come non recapitabile. Tuttavia, data la pianificazione dei retry, l'impostazione su 10 del numero massimo di retry di recapito non produce alcun impatto perché gli eventi diventeranno non recapitabili prima, dopo 20 minuti. Questo è dovuto al fatto che al minuto 20 si verifica il tentativo di recapito #8 (0, 10s, 30s, 1m, 5m, 10m, 15m, 20m) ma in quel momento l'evento viene inserito come non recapitabile.
Suddivisione in batch per l'output
Se come tipo di endpoint di destinazione si usano i Webhook, per impostazione predefinita Griglia di eventi invia ogni evento singolarmente ai sottoscrittori. È possibile configurare Griglia di eventi in batch per il recapito, al fine di migliorare le prestazioni HTTP negli scenari con velocità effettiva elevata. Per impostazione predefinita l'invio in batch è disattivato e può essere attivato per ogni sottoscrizione di eventi.
Se come tipo di endpoint di destinazione si usa Hub eventi, Griglia di eventi esegue il batch degli eventi per massimizzare l’efficienza e le prestazioni. Una configurazione dei criteri batch non esiste: per impostazione predefinita Griglia di eventi gestisce il comportamento di invio in batch per il recapito a Hub eventi di Azure.
Criteri per l’invio in batch
Il recapito in batch ha due impostazioni:
- Numero massimo di eventi per batch: numero massimo di eventi che Griglia di eventi recapita per ogni batch. Il valore deve essere un numero intero compreso tra 1 e 5.000. Questo numero non viene mai oltrepassato. Tuttavia, se al momento del recapito non sono disponibili altri eventi, è possibile recapitarne un numero inferiore. Griglia di eventi non ritarda gli eventi per creare un batch se sono disponibili meno eventi.
- Dimensioni batch preferite in KB: valore di destinazione per le dimensioni del batch in kilobyte. Il valore deve essere un numero compreso tra 1 e 1024. Analogamente al numero massimo di eventi, le dimensioni del batch possono essere inferiori se al momento del recapito non sono disponibili altri eventi. È possibile che un batch superi le dimensioni del batch preferite se un singolo evento supera le dimensioni preferite. Ad esempio, se la dimensione preferita è 4 Kb e in Griglia di eventi viene eseguito il push per un evento di 10 Kb, l’evento da 10 Kb viene recapitato anziché essere eliminato.
Il recapito in batch viene configurato su una base di sottoscrizione per evento, tramite portale, interfaccia della riga di comando, PowerShell o SDK.
Comportamento di invio in batch
Tutti o nessuno
Griglia di eventi funziona con la semantica tutti o nessuno. Non supporta l'esito parziale di un recapito batch. I sottoscrittori devono prestare attenzione e richiedere solo il numero di eventi per batch che possono ragionevolmente gestire in 30 secondi.
Invio in batch Optimistic
Le impostazioni dei criteri di invio in batch non presentano limiti rigorosi per il comportamento di invio in batch, e il rispetto delle stesse avviene su una base di massimo impegno. A bassa frequenza di eventi, spesso si osserva che le dimensioni del batch sono inferiori al massimo di eventi richiesti per batch.
Il valore predefinito è impostato su OFF
Per impostazione predefinita, Griglia di eventi aggiunge un solo evento a ciascuna richiesta di recapito. Per attivare l'invio in batch scegliere una delle impostazioni indicate in Criteri di invio in batch.
Valori predefiniti
Durante la creazione di una sottoscrizione di eventi, non è necessario specificare entrambe le impostazioni (Numero massimo di eventi per batch e Dimensioni batch approssimative in kilobyte). Se ne è impostata solo una, Griglia di eventi usa i valori predefiniti. Per i valori predefiniti e informazioni su come eseguirne l'override, vedere le sezioni seguenti.
Azure portal
Queste impostazioni sono visualizzate nella scheda Funzionalità aggiuntive della pagina Sottoscrizione evento o una volta creata la sottoscrizione di dell’evento, nell'opzione del menu Configurazione quando si accede a Sottoscrizione evento.
Eventi relativi ai messaggi non recapitabili
Se Griglia di eventi non può recapitare un evento entro un determinato periodo di tempo o dopo aver tentato di recapitare l'evento un determinato numero di volte, invia l'evento a un account di archiviazione. Questo processo è noto come inserimento nella coda di eventi non recapitabili. Griglia di eventi inserisce un evento nella coda di eventi non recapitabili quando si verifica una delle condizioni seguenti.
- L'evento non viene recapitato entro il periodo di durata (la conservazione dati è definita nella sottoscrizione di eventi).
- Il numero di tentativi di recapito dell'evento ha superato il limite.
Se una delle condizioni viene soddisfatta, l'evento viene eliminato o inserito come non recapitabile. Per impostazione predefinita, Griglia di eventi non attiva l'inserimento nella coda di eventi non recapitabili. Per abilitarlo, è necessario specificare che un account di archiviazione deve contenere gli eventi non recapitati durante la sottoscrizione di eventi. Per risolvere i recapiti, è possibile leggere gli eventi in questo account di archiviazione.
Griglia di eventi invia un evento nel percorso dell'evento non recapitato quando ha eseguito tutti i tentativi di ripetizione. Se Griglia di eventi riceve un codice di risposta 400 (Richiesta non valida) o 413 (Entità della richiesta troppo grande), pianifica immediatamente l'invio dell'evento alla coda degli eventi non recapitabili. Questi codici di risposta indicano che recapito dell'evento non avrà mai esito positivo.
La scadenza della durata viene controllata SOLO al tentativo di recapito pianificato successivo. Pertanto, anche la durata scade prima del successivo tentativo di recapito pianificato, la scadenza dell'evento viene controllata solo al momento del recapito successivo, e in seguito diviene non recapitabile.
Tra l'ultimo tentativo di recapitare un evento e il momento in cui questo viene recapitato alla posizione dei messaggi non recapitabili, trascorre un intervallo di cinque minuti. Tale ritardo ha lo scopo di ridurre il numero di operazioni di archiviazione BLOB. Se la posizione dei messaggi non recapitabili non è disponibile per quattro ore, l'evento viene eliminato.
Prima di impostare la posizione dei messaggi non recapitabili, è necessario avere un account di archiviazione con un contenitore. L'endpoint di questo contenitore deve essere specificato durante la creazione della sottoscrizione di eventi. Di seguito è indicato il formato dell'endpoint: /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>
Quando un evento è stato inviato al percorso di messaggi non recapitabili potrebbe essere opportuno ricevere una notifica. Per usare Griglia di eventi per rispondere a eventi non recapitati, creare una sottoscrizione di eventi per l'archivio BLOB di eventi non recapitabili. Ogni volta che l'archivio BLOB riceve un evento non recapitato, Griglia di eventi invia una notifica al gestore. Il gestore risponde con le azioni da eseguire per la riconciliazione degli eventi non recapitati.
Quando si configurano messaggi non recapitabili, è necessario aggiungere l'identità gestita al controllo degli accessi in base al ruolo (RBAC) appropriato, nell'account di Archiviazione di Azure che conterrà gli eventi non recapitabili. Per altre informazioni, vedere Destinazioni supportate e ruoli di Azure.
Formati degli eventi di recapito
Questa sezione offre esempi di eventi/eventi non recapitabili usando lo schema CloudEvents 1.0, ossia il formato dei metadati del messaggio supportato negli argomenti dello spazio dei nomi.
Schema CloudEvents 1.0
Event
{
"id": "caee971c-3ca0-4254-8f99-1395b394588e",
"source": "mysource",
"dataversion": "1.0",
"subject": "mySubject",
"type": "fooEventType",
"datacontenttype": "application/json",
"data": {
"prop1": "value1",
"prop2": 5
}
}
Evento di messaggi non recapitabili
[
{
"deadLetterProperties": {
"deadletterreason": "Maximum delivery attempts was exceeded.",
"deliveryattempts": 1,
"deliveryresult": "Event was not acknowledged nor rejected.",
"publishutc": "2023-11-01T20:33:51.4521467Z",
"deliveryattemptutc": "2023-11-01T20:33:52.3692079Z"
},
"event": {
"comexampleextension1": "value1",
"id": "A234-1234-1234",
"comexampleothervalue": "5",
"datacontenttype": "text/xml",
"specversion": "1.0",
"time": "2018-04-05T17:31:00Z",
"source": "/mycontext",
"type": "com.example.someevent",
"data": <your-event-data>
}
}
]
LastDeliveryOutcome: in prova
Se i recapiti di un evento a una destinazione iniziano a dare esito negativo, la Griglia di eventi mette in prova una sottoscrizione di eventi per un determinato periodo. Il tempo di prova varia a seconda dei diversi errori restituiti dall'endpoint di destinazione. Per una sottoscrizione di eventi in prova, gli eventi possono ricevere messaggi non recapitabili o eliminati anche senza tentare il recapito, a seconda del codice di errore che ne causa la messa in prova.
Error | Durata della prova |
---|---|
Occupato | 10 secondi |
NotFound | 5 minuti |
SocketError | 30 secondi |
ResolutionError | 5 minuti |
Disabilitata | 5 minuti |
Completa | 5 minuti |
TimedOut | 10 secondi |
Non autorizzata | 5 minuti |
Non consentito | 5 minuti |
InvalidAzureFunctionDestination | 10 minuti |
Nota
Griglia di eventi usa la durata della messa in prova per una migliore gestione del recapito e tale durata potrebbe cambiare in futuro.
Stato di recapito del messaggio
Griglia di eventi usa i codici di risposta HTTP per confermare la ricezione degli eventi.
Codici di riuscita
Griglia di eventi considera come recapito con esito positivo solo i codici di risposta HTTP seguenti. Tutti gli altri codici di stato sono giudicati come recapiti con esito negativo e sarà eseguito il retry o considerati non recapitabili, a seconda del caso. Quando Griglia di eventi riceve un codice di stato riuscito, considera il recapito come completato.
- 200 OK
- 201 Creato
- 202 - Accettato
- 203 Informazioni non autorevoli
- 204 No Content
Codici di errore
Tutti gli altri codici non inclusi nel set precedente (200-204) sono considerati errori e sarà eseguito il retry,se necessario. Alcuni dispongono di criteri di retry specifici associati, descritti di seguito. Tutti gli altri seguono la pianificazione standard di pianificazione dei retry. È importante tenere presente che, data la natura altamente parallelizzata dell'architettura di Griglia di eventi, il comportamento dei retry è non deterministico.
Codice di stato | Comportamento in caso di nuovo tentativo |
---|---|
400 Richiesta non valida | Retry non eseguito |
401 - Non autorizzato | Eseguire il retry dopo 5 minuti o più per gli endpoint delle risorse di Azure |
403 Negato | Retry non eseguito |
404 Not Found | Eseguire il retry dopo 5 minuti o più per gli endpoint delle risorse di Azure |
408 - Timeout richiesta | Eseguire il retry dopo 2 minuti o più |
413 Entità della richiesta troppo grande | Retry non eseguito |
503 Servizio non disponibile | Eseguire il retry dopo 30 secondi o più |
Tutti gli altri | Eseguire il retry dopo 10 secondi o più |
Proprietà di recapito personalizzate
Le sottoscrizioni di eventi consentono di configurare le intestazioni HTTP incluse negli eventi recapitati. Questa funzionalità consente di impostare le intestazioni personalizzate richieste da una destinazione. È possibile configurare fino a 10 intestazioni durante la creazione di una sottoscrizione di eventi. Ogni valore di intestazione non deve superare 4.096 byte (4K). È possibile impostare intestazioni personalizzate sugli eventi recapitati alle destinazioni seguenti:
- Webhooks
- Hub eventi di Azure