Email e SMS transazionali
I messaggi di registrazione, ricevuta e reimpostazione vengono messi in coda dall'app web e inviati da un pool di worker.
Dati di baseLavoro in background
Code di job
Code FIFO che non perdono job quando un worker muore, con producer e consumer in parallelo.
- LPUSH/s in pipeline, misurati
- 31.6M
- job persi in un crash
- 0
- polling
- 0
Passo 1 di 5
I producer inseriscono i job
Qualsiasi servizio aggiunge lavoro senza aspettare i consumer.
Sessione di esempioplaying
# I producer inseriscono i job
hotkv> LPUSH queue:emails "{\"to\":\"ada@example.com\",\"tpl\":\"welcome\"}"
(integer) 18
Una dimostrazione animata con comandi HotKV reali e risposte di esempio. Clicca su un passo qualsiasi per andarci. Comandi e risposte restano in inglese, esattamente come li digiti e li vedi in HotKV.
Il problema
Il lavoro in background come email, ridimensionamento di immagini e webhook ha bisogno di una coda tra il codice che lo crea e il codice che lo esegue. Una coda che perde un job quando un worker si blocca a metà è peggio di nessuna coda, perché nessuno si accorge che il job è sparito.
Come lo gestisce HotKV
Le liste ti danno una semplice coda FIFO. BLMOVE sposta ogni job in una lista di elaborazione nel momento in cui viene consegnato a un worker, quindi un job in corso è sempre salvato da qualche parte se quel worker scompare. Producer e consumer sono serviti da thread worker paralleli.
Passo dopo passo
Cosa succede, comando per comando
- 01
I producer inseriscono i job
Qualsiasi servizio aggiunge lavoro senza aspettare i consumer.
LPUSH queue:emails "{\"to\":\"ada@example.com\",\"tpl\":\"welcome\"}" - 02
Un worker prende un job in sicurezza
BLMOVE resta in attesa finché un job è disponibile, poi lo sposta in una lista di elaborazione in un solo passo.
BLMOVE queue:emails queue:emails:processing RIGHT LEFT 0 - 03
Conferma quando hai finito
L'email è partita. Il job viene rimosso dalla lista di elaborazione.
LREM queue:emails:processing 1 "{\"to\":\"ada@example.com\",\"tpl\":\"welcome\"}" - 04
Un worker si blocca
Il worker 2 muore a metà job. Il suo job è ancora nella lista di elaborazione, non perso.
LRANGE queue:emails:processing 0 -1 - 05
Rimetti in coda e vai avanti
Un monitor riporta il job abbandonato nella coda e un altro worker lo prende.
LMOVE queue:emails:processing queue:emails LEFT RIGHT
Dove si usa
Scenari reali
Elaborazione di media
I caricamenti vengono messi in coda per miniature e transcodifica, e un transcoder che si blocca non perde mai un file.
Consegna dei webhook
I webhook in uscita vengono messi in coda e ritentati senza bloccare la richiesta che li ha generati.
Integrato
Cosa ottieni
FIFO con letture bloccanti
LPUSH con BRPOP, e i worker dormono finché non arriva lavoro.
LPUSHBRPOPNessun job perso
BLMOVE consegna ogni job a una lista di elaborazione in modo atomico.
BLMOVELREMProducer e consumer in parallelo
Producer e consumer sono serviti da thread worker paralleli.
Ti serve di più?
Per conferme, consumer group e replay, usa gli stream.
XADDXREADGROUPDomande frequenti
Cosa succede a un job se un worker si blocca?
Se prendi i job con BLMOVE, il job resta nella lista di elaborazione. Un monitor può riportare in coda tutto ciò che è rimasto lì troppo a lungo.
I worker devono fare polling?
No. BRPOP e BLMOVE restano in attesa finché arriva un job, con un timeout opzionale.
Liste o stream?
Le liste sono la coda più semplice. Gli stream aggiungono consumer group, conferma per singolo messaggio e cronologia. Vedi il caso d'uso sullo streaming di eventi.
Casi d'uso correlati
Provalo sul tuo carico di lavoro
HotKV parla il protocollo Redis, quindi puoi puntarci un client esistente ed eseguire questi stessi comandi.