什么是"处理为消息"工作队列的Erlang设计模式？

Question

我试图弄清楚在erlang谈话中提到的设计模式.基本上,发言者提到使用"消息作为进程"的工作队列而不是将作业用作进程.

关键的想法是,通过使用"消息作为进程",您可以节省序列化/反序列化开销.

谢谢

Answer 1

让我们M成为一个Erlang术语(),它是我们在系统中发送的消息.一个明显的处理方法M是构建进程和队列的管道.M由管道中的第一个worker处理,然后发送到下一个队列.然后由下一个工作进程拾取,再次处理并放入队列.依此类推,直到消息完全处理完毕.

也许不那么明显的方法是定义一个过程P,然后M交给P.我们将其标记为P(M).现在,消息本身是一个过程,而不是一段数据.P将完成工作人员在队列解决方案中所做的同样的工作,但是它不必支付将M后端插入队列并再次将其取下等的开销.处理P(M)完成后,该过程将简单地结束其生命.如果传递另一条消息,M'我们将简单地生成P(M')并让它同时处理该消息.如果我们得到一组流程,我们会这样做[P(M) || M <- Set]等等.

如果P需要进行同步或消息传递,它可以在不必"模拟"消息的情况下这样做,因为它是消息.与工作队列方法相比较,工作人员必须对其附带的消息负责.如果P有错误,则只有P(M)受错误影响的邮件才会崩溃.再次,与工作队列方法相比,管道中的崩溃可能会影响其他消息(主要是如果管道设计不当).

所以结论是:将消息转换为成为消息的进程.

这个成语是"每个消息一个进程",在Erlang中很常见.制作新流程的价格和开销足够低,这是有效的.如果您使用这个想法,您可能需要某种过载保护.原因是您可能希望限制并发请求的数量,以便您控制系统的负载,而不是盲目地让它破坏您的服务器.其中一个实现是由Erlang Solutions创建的Jobs,请参阅

https://github.com/esl/jobs

和Ulf Wiger将在以下时间展示:

http://www.erlang-factory.com/conference/ErlangFactoryLiteLA/speakers/UlfWiger

正如Ulf在谈话中暗示的那样,我们通常会在外部P进行一些预处理来解析消息并将其内化到Erlang系统.但只要可能,我们就会使消息M成为工作通过在包装过程中它(P(M)).因此,我们立即获得了Erlang Scheduler的好处.

这个选择还有另一个重要的分支:如果处理消息需要很长时间,那么Erlang的抢占式调度程序将确保处理需求较少的消息仍然可以快速处理.如果您的工作队列数量有限,最终可能会阻塞许多工作队列,从而影响系统的吞吐量.