RabbitMQ 4

AMQP 1.0 come protocollo di base: per ulteriori informazioni, consulta Protocolli.

Pale locali: le pale ora supportano un nuovo protocollo chiamato «locale» oltre a AMQP 0-9-1 e AMQP 1.0. Gli shovel locali si basano internamente su AMQP 1.0 ma invece di utilizzare connessioni TCP separate, utilizzano connessioni intra-cluster tra i nodi del cluster e interne per la pubblicazione e il consumo di messaggi. APIs Può essere utilizzato solo per l'utilizzo e la pubblicazione all'interno dello stesso cluster e può offrire un throughput più elevato utilizzando meno risorse rispetto a AMQP 0-9-1 e AMQP 1.0.

Le code quorum supportano le priorità dei messaggi: le priorità dei messaggi della coda quorum sono sempre attive e non richiedono una policy per funzionare. Non appena una coda quorum riceve un messaggio con una priorità impostata, abilita l'assegnazione delle priorità. Le code quorum supportano internamente solo due priorità: alta e normale. I messaggi senza una priorità impostata verranno mappati alla normalità così come le priorità da 0 a 4. I messaggi con una priorità superiore a 4 verranno mappati come alta. I messaggi ad alta priorità verranno privilegiati rispetto ai messaggi con priorità normale con un rapporto di 2:1, vale a dire per ogni 2 messaggi ad alta priorità la coda consegnerà 1 messaggio con priorità normale (se disponibile). Pertanto, le code quorum implementano una sorta di elaborazione delle priorità non rigorosa e basata sulla «condivisione equa». Ciò garantisce che si compiano sempre progressi sui messaggi con priorità normale, ma si privilegiano priorità elevate con un rapporto di 2:1.

Khepri: Khepri viene utilizzato come archivio di metadati predefinito per i broker RabbitMQ 4

Mutual TLS (mTLS): Amazon MQ supporta il protocollo TLS reciproco (MTLS) per i broker RabbitMQ, consentendo ai clienti di autenticarsi tramite certificati. Per ulteriori informazioni, consulta la configurazione di mTLS.

Plugin di autenticazione dei certificati SSL: il plug-in di autenticazione SSL utilizza i certificati client delle connessioni MTLS per autenticare gli utenti, consentendo l'autenticazione tramite certificati client X.509 anziché credenziali di nome utente e password. Per ulteriori informazioni, consulta Autenticazione tramite certificato SSL.

Plugin di autenticazione HTTP: il plug-in di backend di autenticazione HTTP consente di delegare l'autenticazione e l'autorizzazione a un servizio HTTP esterno. Per ulteriori informazioni, consulta Autenticazione e autorizzazione HTTP.

Mirroring delle code classiche: le code classiche continuano a essere supportate senza modifiche sostanziali per le librerie e le applicazioni client, ma ora sono un tipo di coda non replicato. I client saranno in grado di connettersi a qualsiasi nodo per pubblicare e consumare contenuti da qualsiasi coda classica non replicata. Le code quorum sono consigliate per la replica e la sicurezza dei dati.

Rimozione del QoS globale: si consiglia ai clienti di impostare il QoS per consumatore (non globale) anziché il QoS globale, in cui viene utilizzato un singolo prefetch condiviso per un intero canale.

Support per code transitorie e non esclusive: le code transitorie sono code la cui durata è legata all'uptime del nodo su cui sono dichiarate. In un broker a singola istanza, vengono rimosse al riavvio del nodo. In una distribuzione di cluster, vengono rimossi al riavvio del nodo su cui sono ospitati. Ti consigliamo di utilizzare queue TTL per eliminare automaticamente le code inutilizzate e inattive dopo un certo periodo di inattività. Le code esclusive continuano a essere supportate e vengono eliminate una volta rimosse tutte le connessioni alla coda.

Tipo di coda predefinito: Il tipo di coda predefinito su un broker RabbitMQ 4 è impostato sul quorum. Se non viene specificato alcun argomento sul tipo di coda durante la creazione della coda, verrà creata una coda di quorum.

Il limite di riconsegna predefinito per le code del quorum è impostato su 20: i messaggi che vengono riconsegnati 20 o più volte verranno respinti o eliminati (rimossi). Se uno scenario comune per una coda è di 20 recapiti per messaggio, per tali code è necessario configurare un obiettivo con lettera morta o un limite superiore per evitare la perdita di dati. Il modo consigliato per farlo è tramite una politica.

amqplib: le versioni amqplib del client Node JS precedenti alla 0.10.7 o qualsiasi libreria client AMQP che utilizza frame_max < 8192 non saranno in grado di connettersi a RabbitMQ

Limiti predefiniti delle risorse: Amazon MQ per RabbitMQ ha introdotto limiti predefiniti di utilizzo delle risorse per connessioni, canali, consumatori per canale, code, vhost, pale, scambi e dimensione massima dei messaggi. Questi fungono da barriere per proteggere la disponibilità dei broker e possono essere personalizzati utilizzando configurazioni per soddisfare requisiti specifici.

Scambi casuali locali: gli scambi casuali locali non sono supportati su Amazon MQ poiché i nodi Amazon MQ sono protetti da un sistema di bilanciamento del carico di rete.

Message Interceptor: gli intercettori di messaggi RabbitMQ non sono supportati su Amazon MQ.

Parametri per coda: Amazon MQ non fornirà i parametri della coda RabbitMQ per i broker RabbitMQ 4. AWS CloudWatch Amazon MQ continuerà a fornire parametri a livello di broker. AWS CloudWatch Puoi interrogare i parametri della coda utilizzando l'API di gestione RabbitMQ. Consigliamo di interrogare le metriche per code specifiche a intervalli di un minuto o più.