Laravel Horizon e Supervisor risolvono problemi diversi. Horizon gestisce i worker delle code Redis e offre una vista del lavoro; Supervisor può mantenere in esecuzione il processo Horizon e riavviarlo quando termina.
Il confronto utile riguarda quindi la gestione dei job: quando bastano worker configurati direttamente e quando serve una console con bilanciamento e osservabilità. Eliminare il process monitor non è il beneficio che cercherei introducendo Horizon.
Separare processo, coda e risultato
Un processo in esecuzione non dimostra che il lavoro proceda. La coda può accumularsi per un servizio esterno lento, un errore ripetuto o una capacità insufficiente. Viceversa, un worker riavviato correttamente non dimostra che l’operazione precedente sia stata completata una sola volta.
Per un job che pubblica un articolo distinguerei attesa, avvio, tentativi ed esito sul sito remoto. Il risultato applicativo è una pubblicazione verificata, non semplicemente la scomparsa del job dalla lista.
Che cosa aggiunge Horizon
La documentazione Horizon descrive monitoraggio, configurazione dei supervisor interni e strategie di bilanciamento per code Redis. La stessa guida mostra come usare Supervisor per controllare il processo principale.
Una dashboard comune può ridurre il lavoro necessario a trovare i fallimenti. Tag coerenti aiutano a riconoscere i job, ma non sostituiscono una progettazione delle metriche. Una media dei tempi non è un percentile, e il dettaglio disponibile deve essere verificato rispetto alla domanda operativa.
Limiterei l’accesso alla console. Payload, eccezioni e nomi delle risorse possono contenere dati che non devono essere visibili a tutti gli utenti del prodotto.
Coordinare timeout e nuovi tentativi
Il timeout del worker deve lasciare un margine prima del retry_after della connessione. In caso contrario, un job può tornare disponibile mentre un altro processo lo sta ancora eseguendo. Vanno considerati anche timeout del singolo job e delle chiamate di rete.
La guida alle code Laravel è il riferimento per la configurazione della connessione e del ciclo di lavoro. I valori devono derivare dalla durata attesa e dai limiti delle dipendenze, non essere copiati da un esempio generico.
Usare un solo worker riduce alcune forme di concorrenza, ma non elimina duplicazioni dopo un crash o una risposta persa. Le operazioni con effetti esterni richiedono identificatori stabili, verifica dell’esito e meccanismi di idempotenza compatibili con il servizio coinvolto.
Preparare rilascio e capacità
I worker persistenti devono caricare il nuovo codice durante il deploy. Il tempo concesso all’arresto deve essere coerente con i job in corso; una terminazione forzata richiede una strategia di recupero.
Separerei lavori brevi e operazioni lunghe quando competono per la stessa capacità. Aumentare i processi senza controllare database e provider può peggiorare la coda anziché svuotarla.
Sceglierei Horizon quando rende più semplice osservare e governare questo comportamento. La verifica finale resta un insieme di prove sul lavoro reale: errore, riavvio, retry e rilascio mentre ci sono job attivi.