Líder/Seguidor vs cola de trabajos

Question

Acabo de leer un artículo sobre el Leader/Follower Pattern y si lo entendí correctamente, mantengo a mis trabajadores en cola y el primer trabajador recibe una solicitud entrante y se separa de la cola.

Con una cola de trabajos normal (rabbitmq y beanstalkd, por ejemplo) es al revés: mantengo mis trabajos en una cola y una vez que un trabajador termina de procesar, solo toma el primer trabajo de la cola.

¿Hay algo que me falta?

Entonces, ¿cuáles son las ventajas que debo usar un enfoque Leader/Follower en lugar de una cola de trabajo? O al revés, ¿en qué situaciones se adapta mejor una cola de trabajo?

adiós, Nico

Answer 1

líder/es tratar sobre eficientemente con varios trabajadores. Cuando no tiene trabajo (trabajos), ¿qué está haciendo su trabajador o sus trabajadores? Un enfoque simple y común es hacer que un hilo de consumidor único envíe trabajos a los trabajadores, ya sea generando un hilo o usando un grupo de hilos. El patrón discutido proporciona un enfoque alternativo que evita tener que sincronizar entre el despachador y el trabajador al tener el hilo (líder) que hace que el trabajo ejecute la tarea de trabajo. Promueve a un trabajador que espera a la posición de líder para mantener el sistema receptivo.

Tenga en cuenta que este artículo está discutiendo mecanismos de bajo nivel para esperar el trabajo que no admite (fácilmente) varios subprocesos esperando en la misma "cola" de trabajo. Las construcciones de nivel superior, como las colas de mensajes que sí admiten subprocesos de trabajo múltiples, todas realizando una lectura de bloqueo en la misma fuente (consumidores que compiten con AKA) pueden no obtener el mismo beneficio descrito. Con un mayor nivel de abstracción, se obtiene una mayor facilidad de programación, pero normalmente a costa del tipo de rendimiento que se puede obtener con un enfoque de menor nivel.

EDIT1:

He aquí una muestra maquillada (pseudocódigo solamente). Tenga en cuenta que no escribí el artículo ni lo comparé, así que no puedo hablar sobre el rendimiento de uno frente al otro. Pero con suerte, esto muestra la diferencia de estilo.

// in QueueHandler processing loop 

while(true) 
{ 
    // read, blocking until one arrives 
    Request req = requestQueue.BlockingRead(); 

    // we have a unit of work now but the QueueHandler should not process it 
    // because if it is long running then no new requests can be handled. 
    // so we spawn/dispatch to a thread 
    ThreadPool.QueueWorkItem(req); 
    // or new Thread(DoWork(), req).Start; 

    // at this point we know that the request will get picked up in 
    // an unknown but hopefully very short amount of time by a 
    // waiting (sleeping/blocking) or new thread and it will get passed the 
    // work. But doing so required the use of thread synchronization 
    // primitives that can cause all processors to flush their caches 
    // and other expensive stuff. 


} // now loop back up to read the next request 

VS

// in Leader 

while(true) 
{ 

    // I'm the leader, blocking read until a request arrives 
    Request req = queue.BlockingRead(); 

    // We have a unit of work and we are going to process it ourselves. 
    // But first we notify a follower. 
    Followers.PromoteOne(); 

    // work on the request in this thread! 
    DoWorkOn(req); 

    // now that I'm done, wait to the the leader 
    Followers.BlockingWaitToBeLeader(); 

} 

Answer 2

primer lugar con colas de trabajo que tiene cerraduras en las colas de trabajo. En segundo lugar, y ese es el problema principal, con colas de trabajo, debe activar un subproceso de trabajo y ese subproceso no procesará el trabajo hasta que el planificador de tareas del sistema realmente ejecute la tarea. Lo que empeora cuando procesa el elemento de trabajo con un núcleo de procesador diferente al que llena la cola. Para que pueda lograr latencias mucho más bajas con un patrón de seguidor líder.