Messaggi di Fan Out a molti gruppi di consumer in una coda

Distribuisci i messaggi da un'unica OCI Queue a molti gruppi di consumer e applica filtri per ogni gruppo, abilitando la messaggistica application-to-app scalabile, a bassa latenza e basata su pull

Con il fanout, puoi inviare un messaggio a diversi gruppi di consumatori contemporaneamente, semplificando la condivisione degli aggiornamenti con molti team o servizi da una sola coda. Questo è utile perché puoi controllare esattamente chi riceve i messaggi, quindi ogni gruppo vede solo ciò che è rilevante per loro.

Per utilizzare il fanout, è possibile creare filtri che valutano gli attributi dei messaggi allegati a ciascun messaggio. Solo i gruppi di consumer per i quali il filtro restituisce true ricevono il messaggio.

Gruppi di consumer

Un gruppo di consumatori è un percorso di consegna logico persistente all'interno di una coda. Ogni gruppo di consumer riceve i messaggi separatamente, in base ai filtri impostati.
Nota

È necessario abilitare i gruppi di consumer prima di poterli utilizzare in una coda. È possibile eseguire questa operazione quando si crea o si modifica una coda.
Quando si abilitano i gruppi di consumer per una coda, il servizio Queue crea automaticamente un gruppo predefinito denominato gruppo di consumer primario. Anche se non è possibile aggiungere filtri al gruppo predefinito o eliminarlo, è possibile disabilitarlo se necessario. Si può pensare a questo gruppo come a un superset: finché è abilitato, riceve tutti i messaggi pubblicati nella coda, indipendentemente dai filtri impostati per altri gruppi.
Nota

Il gruppo principale garantisce che ogni messaggio abbia una destinazione. Quando si imposta il gruppo di consumer principale come inattivo, non si ricevono messaggi tramite tale gruppo. Il sistema elimina tutti i messaggi inviati mentre il gruppo principale è inattivo e che non corrispondono ai filtri in altri gruppi; questi messaggi non possono essere recuperati. Per evitare di perdere messaggi, mantenere abilitato il gruppo di consumer primario a meno che non si intenda eliminare in modo specifico alcuni messaggi.

Oltre al gruppo di consumer predefinito, è possibile aggiungere tutti i gruppi di consumer necessari per consegnare messaggi a consumer specifici. Ogni gruppo opera in modo indipendente dagli altri, quindi i messaggi vengono consegnati, filtrati e monitorati separatamente, garantendo isolamento e correttezza tra i consumatori. È possibile impostare un filtro per ciascun gruppo per controllare i messaggi ricevuti. Se non si imposta un filtro o si lascia vuoto il filtro, il gruppo riceve tutti i messaggi, come avviene per il gruppo predefinito.

Di seguito è riportata una panoramica delle differenze tra il gruppo di consumer predefinito (primario) e i gruppi di consumer creati.

Funzione Gruppo di consumatori predefinito (principale) Altri gruppi di consumatori
Creazione Creato automaticamente quando i gruppi di consumer sono abilitati Creato manualmente in base alle esigenze
Può essere eliminato N
Disabilitabile
Può contenere filtri N
Riceve tutti i messaggi Sì, se abilitato Solo i messaggi che corrispondono al filtro oppure tutti i messaggi se non è impostato alcun filtro
È possibile impostare il conteggio delle consegne DLQ N
OCID Uguale all'OCID coda OCID univoco per gruppo

Esempio di uso

Si supponga di creare una coda per gli eventi di fatturazione. Il gruppo di consumer predefinito è per il team di conformità alla fatturazione, che deve ricevere tutti i messaggi per motivi di conformità. È inoltre possibile aggiungere un altro gruppo di consumer per il team che gestisce le spese esecutive e impostare un filtro in modo che questo gruppo riceva solo messaggi con l'attributo team = "exec-expenses". Ciò riduce il rumore per il team delle spese esecutive assicurando che ricevano solo messaggi pertinenti.

Messaggi e attributi

Un messaggio può facoltativamente includere attributi, coppie chiave-valore aggiunte dal producer come informazioni aggiuntive (metadati). Gli attributi possono descrivere qualsiasi dettaglio sul messaggio (ad esempio, area, priorità o tipo di evento) e consentono di eseguire filtri con filtro e targeting dettagliati dei messaggi ai gruppi di consumer.

Di seguito sono riportate alcune linee guida per i producer durante la creazione degli attributi.

  • Le chiavi e i valori degli attributi distinguono tra maiuscole e minuscole.
  • I valori degli attributi devono essere uno dei seguenti tipi di dati supportati:
    • Stringa: stringa con codifica UTF-8.
    • Numero: valore numerico intero o decimale.
  • Conteggio degli attributi per la dimensione totale del messaggio.
Di seguito sono riportati alcuni suggerimenti per la denominazione delle chiavi degli attributi.
  • Le chiavi di attributo devono iniziare con una lettera o un trattino di sottolineatura (_).
  • I tasti attributo possono includere solo lettere, numeri, trattini (-) o caratteri di sottolineatura (_).
  • Non utilizzare le virgolette intorno ai tasti.

Filtraggio

Utilizzare filtri per controllare i messaggi ricevuti da un gruppo di consumer. Quando un messaggio viene pubblicato, Queue Service controlla il filtro in base agli attributi di ciascun messaggio per decidere se il messaggio deve essere consegnato al gruppo di consumer specificato. Un messaggio viene consegnato a un gruppo di consumer solo se il relativo filtro corrisponde agli attributi
Nota

I filtri funzionano solo con gli attributi dei messaggi, non con il corpo del messaggio.

Quando si crea un gruppo di consumer, è possibile creare filtri. Ogni gruppo di consumer può avere un filtro proprio ed è possibile creare un filtro per ogni gruppo di consumer.

Un'espressione di filtro è una regola di tipo SQL che si scrive per decidere quali messaggi riceve un gruppo.

Filtra vincoli espressione

Di seguito sono riportate le regole che definiscono il modo in cui si scrivono e utilizzano le espressioni di filtro, in modo che i filtri funzionino nel modo desiderato.
  • Le espressioni filtro fanno distinzione tra maiuscole e minuscole. Ad esempio, :region = "us-ashburn-1" è diverso da :region = "US-ASHBURN-1".
  • Le espressioni filtro possono avere una lunghezza massima di 256 caratteri.

Filtra valutazione

Di seguito viene descritto cosa accade quando il servizio OCI Queue controlla i filtri e cosa accade ai messaggi che non corrispondono ad alcun filtro.
  • Il servizio coda controlla i filtri solo quando un messaggio viene pubblicato per la prima volta nella coda.
  • Il servizio coda controlla i filtri solo quando un messaggio viene pubblicato per la prima volta nella coda. Se in seguito si riabilita un gruppo di consumer o si modifica il filtro, i messaggi esistenti nella coda non vengono valutati retroattivamente. Solo i nuovi messaggi vengono controllati in base al filtro aggiornato.
  • Se il filtro di nessun gruppo di consumer corrisponde a un messaggio e il gruppo primario è disabilitato, il messaggio viene eliminato e non può essere recuperato. La coda emette una metrica ogni volta che un messaggio viene eliminato. È possibile visualizzare questa metrica nella console in Servizio coda o in Monitoraggio OCI.

Modello espressioni filtro

Di seguito sono riportati i tipi di espressioni filtro che è possibile utilizzare.

Presenza chiave

Utilizzare i filtri di presenza chiave per verificare se un messaggio include o manca un determinato attributo.

Di seguito sono riportate alcune espressioni di filtro di esempio.

  • :region: confronta i messaggi con l'attributo region impostato, indipendentemente dal valore.
  • NOT :region: confronta i messaggi che non hanno l'attributo region.

Filtri stringa

Utilizzare i filtri stringa per abbinare i messaggi in base al valore di un attributo di testo. È possibile verificare la presenza di corrispondenze, differenze o pattern esatti all'interno del testo.

Di seguito sono riportate alcune espressioni di filtro di esempio.

  • :name = "Bob": corrisponde ai messaggi in cui l'attributo name è esattamente 'Bob'.
  • :name != "Bob": corrisponde ai messaggi in cui l'attributo name non è 'Bob'.
  • hasPrefix(:name, "Bo"): corrisponde ai messaggi in cui l'attributo name inizia con 'Bo'.
  • hasSuffix(:name, "ob"): corrisponde ai messaggi in cui l'attributo name termina con 'ob'.
  • NOT hasPrefix(:name, "Bo"): corrisponde ai messaggi in cui l'attributo name non inizia con 'Bo'.

Filtri numerici

Utilizzare filtri numerici per abbinare i messaggi in base al valore di un attributo numerico.

Di seguito ne vengono riportati alcuni esempi.

  • :age = 40: confronta i messaggi in cui l'attributo age è esattamente 40.
  • :age != 40: corrisponde ai messaggi in cui l'attributo age non è 40.
  • :age > 40: corrisponde ai messaggi in cui l'attributo age è maggiore di 40.
  • :age >= 40: confronta i messaggi in cui l'attributo age è maggiore o uguale a 40.
  • :age < 40: corrisponde ai messaggi in cui l'attributo age è minore di 40.
  • :age <= 40: confronta i messaggi in cui l'attributo age è minore o uguale a 40.

Filtri logici

Utilizzare gli operatori logici per combinare le regole e creare filtri più flessibili. Gli operatori supportati sono AND, OR e NOT.
Nota

La precedenza dell'operatore è la seguente: le parentesi ( ) hanno la precedenza più alta, seguite da NOT, quindi AND, quindi OR.

Di seguito ne vengono riportati alcuni esempi.

  • :name = "Bob" AND :age = 40: confronta i messaggi in cui l'attributo name è "Bob" e age è 40.
  • :name = "Bob" OR :age = 40: confronta i messaggi in cui l'attributo name è "Bob" o age è 40.
  • :name = "Bob" AND NOT :age: corrisponde ai messaggi in cui l'attributo name è 'Bob' e non esiste alcun attributo age.

Filtri complessi

Utilizzare una logica più complessa combinando diversi filtri con parentesi e diversi operatori logici.
Nota

La precedenza dell'operatore è la seguente: le parentesi ( ) hanno la precedenza più alta, seguite da NOT, quindi AND, quindi OR.

Di seguito è riportato un esempio.

  • :name = "Bob" AND NOT (:age > 40 OR :location = "Chicago"): confronta i messaggi in cui l'attributo name è "Bob" e age non è superiore a 40 oppure location non è "Chicago".

Criteri IAM

Rivedere i criteri IAM necessari per lavorare con i fanout e i gruppi di consumer.

Best practice

  • Iniziare con piccoli filtri per verificare che la consegna dei messaggi funzioni come previsto. Aggiungi lentamente una logica di filtro complessa, sottoponendola a test.
  • Monitorare la metrica dei messaggi eliminati in OCI Monitoring. Ciò consente di individuare i messaggi eliminati perché non è stato trovato alcun filtro corrispondente.
  • Utilizzare una denominazione coerente per gli attributi dei messaggi di tutti i producer. Ciò rende la scrittura e la manutenzione dei filtri più facili e affidabili.
  • Se una chiave attributo non segue le regole [a partire da una lettera o da un carattere di sottolineatura (_), includere solo lettere, numeri, trattini (-) o caratteri di sottolineatura (_)], aggiungere virgolette nell'espressione del filtro.