我正在尝试找出一个在 erlang 演讲中提到的设计模式。 从本质上讲，演讲者提到了使用“消息作为进程”来使用工作队列，而不是将作业用作进程。
关键思想是，通过使用“消息作为进程”，您可以节省序列化/反序列化开销。
谢谢
【问题讨论】：
标签： design-patterns erlang erlang-otp
让M 成为 Erlang term()，它是我们在系统中发送的 消息。处理M 的一种明显方法是构建进程和队列的管道。 M 由管道中的第一个工作人员处理，然后发送到下一个队列。然后它被下一个工作进程拾取，再次处理并放入队列中。以此类推，直到消息被完全处理。
可能不太明显的方法是定义一个进程P，然后将M 交给P。我们将其标记为P(M)。现在消息本身是一个进程，而不是一个数据。 P 将完成与工作人员在队列解决方案中所做的相同的工作，但它不必支付将M 重新插入队列并再次将其取下等的开销。当处理P(M) 完成时，该进程将简单地结束它的生命。如果传递另一条消息M'，我们将简单地生成P(M') 并让它同时处理该消息。如果我们得到一组进程，我们会做[P(M) || M <- Set]等等。
如果P 需要进行同步或消息传递，它可以这样做而不必“模拟”消息，因为它是消息。与工人队列方法相比，工人必须对随之而来的消息负责。如果P有错误，只有受错误影响的消息P(M)会崩溃。同样，与工作队列方法相比，管道中的崩溃可能会影响其他消息（主要是在管道设计不当的情况下）。
所以总结的诀窍是：将消息转化为成为消息的过程。
成语是“一个进程一个消息”，在 Erlang 中很常见。制作一个新工艺的价格和开销足够低，以至于它可以工作。但是，如果您使用这个想法，您可能需要某种过载保护。原因是您可能希望限制并发请求的数量，以便您控制系统的负载，而不是盲目地让它破坏您的服务器。一种这样的实现是由 Erlang Solutions 创建的 Jobs，请参阅
Ulf Wiger 将在以下地点展示它：
http://www.erlang-factory.com/conference/ErlangFactoryLiteLA/speakers/UlfWiger
正如 Ulf 在演讲中暗示的那样，我们通常会在 P 之外进行一些预处理，以解析消息并将其内部化到 Erlang 系统中。但我们会尽快将消息M 包装在一个进程中（P(M)），使其成为一个job。因此，我们立即获得了 Erlang 调度程序的好处。
这种选择还有另一个重要的后果：如果处理一条消息需要很长时间，那么 Erlang 的抢占式调度器将确保处理需求较少的消息仍然得到快速处理。如果您的工作队列数量有限，最终可能会导致其中许多被阻塞，从而影响系统的吞吐量。
【讨论】：