design-patterns - 领导者/追随者与工作队列

Question

我刚刚阅读了一篇关于 Leader/Follower Pattern 的论文。如果我理解正确，我将我的工作人员放在一个队列中，第一个工作人员接受传入请求并从队列中分离。

使用正常的工作队列(例如 rabbitmq 和 beanstalkd)，反之亦然:我将我的工作保持在队列中，一旦工作人员完成处理，它就会从队列中取出第一个工作。

有什么我想念的吗？

那么，我应该使用 Leader/Follower 方法而不是工作队列有什么优势？或者反过来说，在什么情况下工作队列更适合？

再见，
尼科

Answer 1

领导者/追随者是关于有效地处理多个 worker 。当您没有工作(工作)时，您的 worker 或 worker 在做什么？一种常见的简单方法是让单个消费者线程将作业分派(dispatch)给工作人员，方法是生成线程或使用线程池。所讨论的模式提供了一种替代方法，通过让获取作业的(领导)线程执行工作任务本身来避免在调度程序和工作人员之间进行同步。它将等待的工作人员提升为领导职位，以保持系统响应。

请注意，本文讨论的是等待工作的低级机制，这些机制不(容易)支持多个线程在同一个工作“队列”上等待。像消息队列这样支持多个工作线程的更高级别的构造，它们都在同一源(AKA 竞争消费者)上执行阻塞读取，可能无法获得所描述的相同好处。更高级别的抽象带来更多的编程便利，但通常以从更底层方法获得的性能为代价。

EDIT1:

这是一个虚构的示例(仅限伪代码)。请注意，我没有写这篇文章或对它进行基准测试，所以我不能真正谈论一个与另一个的性能。但希望这显示了风格上的差异。

// 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();

}