Perché risuonare per l'accodamento?
Ho l'impressione che Redis possa essere un buon candidato per l'implementazione di un sistema di accodamento. Fino a questo punto abbiamo utilizzato il nostro database MySQL con il polling o RabbitMQ. Con RabbitMQ abbiamo avuto molti problemi: le librerie client sono molto scarse e buggy e vorremmo non investire troppe ore di sviluppo per risolverle, alcuni problemi con la console di gestione del server, ecc. E, per il momento Almeno, non stiamo afferrando per millisecondi o seriamente spingendo le prestazioni, quindi finché un sistema ha un'architettura che supporta una coda in modo intelligente, probabilmente siamo in buona forma.
Va bene, quindi quello è lo sfondo. In sostanza, ho un modello di coda molto classico e semplice: diversi produttori che producono lavoro e diversi consumatori che consumano lavoro, e sia i produttori che i consumatori devono essere in grado di scalare in modo intelligente. Si scopre che un% ingenuo% co_de non funziona, dal momento che non voglio che gli abbonati tutti consumino lavoro, voglio solo un sottoscrittore uno per ricevere il lavoro. Al primo passaggio, mi sembra che PUBSUB sia un design intelligente.
Possiamo usare BRPOPLPUSH?
Il design di base con BRPOPLPUSH è che hai una coda di lavoro e una coda di progresso. Quando un consumatore riceve un lavoro, spinge atomicamente l'articolo nella coda di avanzamento e quando completa il lavoro, BRPOPLPUSH lo fa. Questo impedisce il blackholing del lavoro se i clienti muoiono e rende il monitoraggio abbastanza semplice: ad esempio, possiamo dire se c'è un problema che porta i consumatori a richiedere molto tempo per eseguire attività, oltre a dire se c'è un grande volume di attività.
Assicura
- il lavoro viene consegnato esattamente a un consumatore Il lavoro di
- si conclude in una coda di progresso, quindi non può creare un buco nero se un consumatore
Gli svantaggi
- Mi sembra piuttosto strano che il miglior design che ho trovato non utilizzi effettivamente
LREMpoiché questo sembra essere quello su cui si concentrano la maggior parte dei post del blog sulla messa in coda su Redis. Quindi mi sento come se mi mancasse qualcosa di ovvio. L'unico modo in cui vedo utilizzarePUBSUBsenza utilizzare le attività due volte è semplicemente di inviare una notifica che il lavoro è arrivato, che i consumatori possono quindi non-blocking-lyPUBSUB. - È impossibile richiedere più di un elemento di lavoro alla volta, il che sembra essere un problema di prestazioni. Non è un grosso problema per la nostra situazione, ma è piuttosto ovvio che questa operazione non è stata progettata per un throughput elevato o questa situazione
- In breve: mi manca qualcosa di stupido?
Aggiungendo anche il tag node.js, perché questa è la lingua con cui principalmente mi occupo. Il nodo può offrire alcune semplificazioni nell'implementazione, data la sua natura single-threaded e nonblocking, ma inoltre sto usando la libreria redis del nodo e le soluzioni dovrebbero o possono essere sensibili ai suoi punti di forza e di debolezza.