Risoluzione dei Problemi Comuni di Configurazione di Redis Pub/Sub

Redis Pub/Sub è così semplice che i team spesso lo trattano come un piccolo broker di messaggi che non necessita di gestione. Un publisher chiama PUBLISH, gli abbonati ricevono i messaggi e tutto sembra istantaneo.

I problemi iniziano quando entrano in gioco reti reali, client lenti, riconnessioni e istanze Redis condivise. Pub/Sub non ha cronologia dei messaggi, nessun riconoscimento e nessuna coda di ripetizione. È un meccanismo di trasmissione in diretta. Se un abbonato è assente, il messaggio è perso per quell'abbonato. Se un abbonato è connesso ma non riesce a leggere abbastanza velocemente, Redis deve trattenere l'output in sospeso per quel client fino a quando un limite configurato lo disconnette.

Questo rende Redis Pub/Sub ottimo per l'invalidazione della cache, aggiornamenti di presenza, dashboard in tempo reale e notifiche "ultimo valore". È poco adatto per flussi di lavoro in cui ogni messaggio deve essere elaborato esattamente una volta o riprodotto dopo un'interruzione. Per questo, considera Redis Streams, RabbitMQ, Kafka o un altro broker con tracciamento delle consegne.

Sintomo: la memoria cresce mentre il traffico Pub/Sub è elevato

Il fallimento più comune di Pub/Sub è un abbonato lento. Il publisher sta bene. Redis è inizialmente a posto. Un consumatore è in ritardo perché il suo processo è in pausa, la sua rete è lenta o esegue lavoro costoso all'interno del gestore di messaggi. Redis continua a scrivere messaggi nel buffer di output di quel client. Se al buffer è permesso crescere senza un limite utile, la pressione sulla memoria si diffonde da un singolo abbonato difettoso all'intera istanza.

Controlla i client:

redis-cli CLIENT LIST

Cerca client con comandi Pub/Sub e grandi quantità di memoria di output:

id=88 addr=10.0.4.12:51244 flags=P db=0 sub=3 psub=0 omem=13421772 obl=128 oll=64 cmd=subscribe

Campi utili:

flags=P indica un client Pub/Sub.
sub e psub mostrano il conteggio delle iscrizioni a canali e pattern.
omem è la memoria del buffer di output in byte.
obl e oll mostrano i dettagli del backlog del buffer di output.
cmd=subscribe o cmd=psubscribe conferma cosa sta facendo il client.

Non farti prendere dal panico per idle negli abbonati. Una connessione Pub/Sub può rimanere inattiva dal punto di vista dei comandi mentre riceve ancora messaggi spinti.

Risolvi i consumatori lenti con i limiti del buffer di output

Redis fornisce ai client Pub/Sub la propria classe di limite del buffer di output:

client-output-buffer-limit pubsub 32mb 8mb 60

Leggilo come:

Disconnetti immediatamente se il buffer di output di un client Pub/Sub raggiunge 32 MB.
Disconnetti se rimane sopra 8 MB per 60 secondi.

I numeri esatti dovrebbero corrispondere al tuo traffico e al comportamento del client. L'errore comune è impostare il limite a 0 0 0 perché le disconnessioni sono fastidiose durante i test. Questo rimuove la barriera di sicurezza. In produzione, una disconnessione è di solito meglio che lasciare che un abbonato bloccato consumi memoria fino a quando Redis diventa instabile.

Dopo aver modificato redis.conf, ricarica o riavvia secondo il tuo processo di deployment. Puoi anche ispezionare il valore in tempo reale:

redis-cli CONFIG GET client-output-buffer-limit

Se usi un servizio Redis gestito, questa impostazione potrebbe essere esposta tramite il gruppo di parametri o l'interfaccia di configurazione del provider, piuttosto che tramite modifica diretta del file.

Sintomo: gli abbonati si connettono ma non ricevono nulla

Inizia con il test più semplice possibile. Apri un terminale:

redis-cli SUBSCRIBE test.channel

Apri un altro:

redis-cli PUBLISH test.channel hello

Se funziona dall'host Redis ma non dalla tua applicazione, probabilmente hai un problema lato client o di rete. Se fallisce ovunque, controlla autenticazione, ACL, routing del cluster e il nome effettivo del canale.

I nomi dei canali sono stringhe di byte esatte. events.user, events:User e events:user sono canali diversi. In sistemi più grandi, preferisco costanti o un piccolo modulo di denominazione dei canali piuttosto che stringhe digitate a mano sparse tra i servizi.

Le iscrizioni a pattern aggiungono un'altra fonte di confusione:

PSUBSCRIBE events:*

Questo corrisponde a events:user.created, ma non a prod:events:user.created. Se la tua applicazione antepone i nomi degli ambienti, includi il prefisso nel pattern.

Problemi di autenticazione e ACL

Le distribuzioni moderne di Redis spesso usano utenti ACL invece di una singola password requirepass condivisa. Un client Pub/Sub ha bisogno del permesso per connettersi, autenticarsi, iscriversi al pattern del canale e talvolta pubblicare.

Un rapido controllo CLI:

redis-cli -u redis://app-user:[email protected]:6379 PING
redis-cli -u redis://app-user:[email protected]:6379 SUBSCRIBE events:test

Sintomi comuni di autenticazione:

NOAUTH Authentication required: il client ha inviato un comando prima di autenticarsi.
WRONGPASS invalid username-password pair: password errata, utente errato o un segreto ruotato non distribuito ovunque.
NOPERM this user has no permissions: l'utente si è autenticato ma manca di permessi per comandi o canali.

Con ACL, i permessi dei canali sono separati dai permessi delle chiavi. Un utente può essere autorizzato a eseguire comandi normali sulle chiavi ma non a iscriversi ai canali che ti aspetti. Rivedi l'utente configurato:

redis-cli ACL GETUSER app-user

Non incollare segreti di produzione nella cronologia della shell durante i test. Usa variabili d'ambiente o una credenziale temporanea quando possibile.

Non condividere le connessioni Pub/Sub con comandi normali

Una volta che una connessione entra in modalità di iscrizione, non è più una normale connessione per comandi Redis. Riceve messaggi spinti e può solo emettere comandi relativi all'iscrizione come SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PING, RESET o comandi di uscita a seconda del client e della versione di Redis.

Se prendi in prestito una connessione da un pool generale e chiami SUBSCRIBE, quella connessione del pool non è più disponibile per GET, SET o altri comandi ordinari. Il risultato può sembrare timeout casuali dell'applicazione perché il pool si riempie lentamente di connessioni bloccate in modalità abbonato.

Usa connessioni separate:

Un client o pool normale per i comandi Redis regolari.
Una connessione di abbonato di lunga durata per ogni processo o thread abbonato.
Una connessione di publisher separata se la tua libreria client lo consiglia.

Molte librerie client forniscono un metodo duplicate() o new connection per questo motivo. Usalo. Non indovinare che il pool risolverà la situazione.

Il comportamento di riconnessione è importante

Pub/Sub non riproduce i messaggi persi dopo la riconnessione. Se un abbonato cade per 30 secondi, ogni messaggio pubblicato durante quella finestra viene perso per quell'abbonato.

Questo è accettabile per l'invalidazione della cache solo se la tua applicazione ha un fallback. Ad esempio, un servizio che perde un evento di invalidazione dovrebbe comunque avere TTL, controlli di versione o un modo per ricostruire dal database di origine. Senza un fallback, un singolo intoppo di rete può lasciare voci di cache locale obsolete per troppo tempo.

Alla riconnessione, assicurati che il client si ri-iscriva a tutti i canali e pattern. Alcune librerie lo fanno automaticamente. Altre richiedono di registrare nuovamente i gestori dopo la riconnessione. Testalo uccidendo la connessione dell'abbonato:

redis-cli CLIENT LIST | grep subscribe
redis-cli CLIENT KILL ID <client-id>

Poi pubblica un messaggio di test e conferma che l'applicazione lo riceve dopo la riconnessione.

L'alto fan-out può diventare pressione su CPU e rete

Il lavoro di PUBLISH cresce con il numero di abbonati e pattern corrispondenti. Un canale con migliaia di abbonati significa che Redis deve spingere il messaggio migliaia di volte. Potrebbe ancora andare bene, ma non è gratuito.

Controlla:

redis-cli INFO stats
redis-cli PUBSUB NUMSUB events:test
redis-cli PUBSUB NUMPAT

PUBSUB NUMSUB aiuta a confermare se un canale ha il numero di abbonati che pensi. PUBSUB NUMPAT è utile perché le iscrizioni a pattern ampi possono sorprenderti. Una manciata di servizi che usano PSUBSCRIBE * o PSUBSCRIBE events:* può ricevere molto più traffico del previsto.

Se il traffico Pub/Sub è importante e ad alto volume, isolalo. Un'istanza Redis dedicata per Pub/Sub protegge la tua cache e il negozio di sessioni dai problemi del buffer degli abbonati e dai picchi di trasmissione. L'istanza dedicata può avere una configurazione ottimizzata per Pub/Sub, preoccupazioni di persistenza più brevi e monitoraggio focalizzato sui client e sull'output di rete.

Mantieni brevi i gestori di messaggi

Un abbonato dovrebbe leggere il messaggio, fare una validazione minima e passare il lavoro a qualcos'altro. Se il gestore chiama un database, fa una richiesta HTTP, renderizza un template o esegue un lungo calcolo prima di leggere il messaggio successivo, può diventare il consumatore lento che stai cercando di evitare.

Forma migliore:

Messaggio Redis -> gestore leggero -> coda locale -> pool di worker

La coda locale può essere una coda in-process, un pool di thread, una coda di attività asincrone o un broker durevole se il lavoro deve sopravvivere ai riavvii del processo. L'idea chiave è che la lettura da Redis non dovrebbe aspettare la dipendenza a valle più lenta.

Se il lavoro deve essere affidabile, Pub/Sub è il primitivo sbagliato. Redis Streams con gruppi di consumatori ti dà voci in sospeso e riconoscimenti. Un broker dedicato potrebbe essere migliore se hai bisogno di code di lettere morte, ripetizioni ritardate, priorità o conservazione lunga.

Una checklist pratica per la risoluzione dei problemi

Quando Pub/Sub sembra malsano, di solito lavoro in questo ordine:

Conferma il canale manualmente con SUBSCRIBE e PUBLISH.
Controlla CLIENT LIST per client Pub/Sub con omem alto.
Ispeziona client-output-buffer-limit pubsub.
Verifica autenticazione e permessi dei canali ACL.
Conferma che gli abbonati usino connessioni dedicate.
Uccidi una connessione abbonato e verifica il comportamento di riconnessione e ri-iscrizione.
Controlla PUBSUB NUMSUB e PUBSUB NUMPAT per fan-out inaspettato.
Decidi se il carico di lavoro ha effettivamente bisogno di Streams o di un broker dedicato.

Redis Pub/Sub è affidabile solo nel senso che fa esattamente ciò che promette: trasmissione di messaggi in diretta agli abbonati attualmente connessi. La maggior parte degli incidenti di produzione deriva dall'aspettarsi che si comporti come una coda durevole. Configura i limiti del buffer, isola il traffico pesante e progetta gli abbonati come se i messaggi potessero essere persi, perché a volte possono esserlo.

Esempio di incidente: una dashboard rallenta la cache

Immagina un'istanza Redis usata per chiavi di cache ordinarie e un piccolo canale Pub/Sub chiamato metrics:live. All'inizio, solo una dashboard interna si iscrive. Mesi dopo, diversi processi gateway del browser si iscrivono anch'essi, e uno di essi inizia a inviare aggiornamenti su connessioni WebSocket lente. Redis non sa che il browser a valle è lento. Vede solo una connessione abbonato che non legge abbastanza velocemente.

Il primo sintomo potrebbe non menzionare affatto Pub/Sub. Le richieste dell'applicazione che usano normali chiamate GET e SET iniziano a scadere. La memoria sale. L'host Redis sembra occupato, ma SLOWLOG non mostra un comando costoso ovvio.

L'indizio utile è in CLIENT LIST:

flags=P sub=1 omem=25165824 cmd=subscribe

Questo ti dice che un client Pub/Sub ha un grande buffer di output. Se il limite rigido configurato è 32 MB, quel client è vicino a essere disconnesso. Se il limite è disabilitato, Redis potrebbe continuare a bufferizzare fino a quando l'intera istanza è sotto pressione di memoria.

La soluzione non è solo aumentare il limite. Aumentarlo potrebbe nascondere il problema e permettere un picco di memoria peggiore la prossima volta. Una risposta migliore è:

Identifica il processo abbonato da addr, name o metadati del client.
Uccidi l'abbonato peggiore se la memoria è a rischio.
Aggiungi o stringi client-output-buffer-limit pubsub.
Sposta la consegna lenta a valle in una coda interna al di fuori del ciclo di lettura di Redis.
Considera di spostare Pub/Sub ad alto volume in un'istanza Redis dedicata.

I nomi dei client rendono tutto molto più facile. Molte librerie Redis permettono di impostare un nome di connessione. Usa nomi come web-1:pubsub-cache-invalidations o dashboard:metrics-live in modo che CLIENT LIST punti al proprietario invece di mostrare solo un IP e una porta.

CLIENT SETNAME dashboard:metrics-live

Questo piccolo accorgimento trasforma un vago incidente di memoria in una conversazione diretta con il team che possiede l'abbonato.