基于actor的范式非常酷。它的有效伸缩能力使它成为任何并发系统都必须评估的范式。我读过一些关于它的资料，并且对它的核心意图有一个不错的想法：用消息和多个“参与者”来驱动昂贵的操作，以最小化由于请求/响应交互而导致的等待，从而提高系统的吞吐量。但是，我还没有足够的机会接触人们使用参与者的设计模式。我正在寻找基于参与者的系统的设计模式。
参与者设计模式的一个常见示例是这样一个系统，其中有一个主协调者参与者和一组子工作者参与者。他们将开销大的操作主Map到较小的块，将较小的块作为消息发送给一组工作者，等待他们的响应，然后将它们全部缩减为结果。在此模式的一些复杂示例中，工作参与者通知主参与者他们已经准备好做更多的工作，主参与者根据需要将更多的工作路由给他们。2这确保了工作的适当平衡，并且在作业大小变化很大时很有用。
我搜索了一下关于更多基于演员的模式的文献，除了上面的例子，我还没有找到任何例子。我还没有通过Akka演员项目的例子，但是任何的指针都是非常有用的。
5条答案
按热度按时间i86rm4rw1#
我强烈推荐Derek Wyatt的“Akka Concurrency“一书--这本书重点介绍了最新的Akka发行版（2.1），并介绍了使用Akka的几个最佳实践和大量的设计模式（强调事件驱动设计）。
Akka Summer of Blog系列的帖子也很有帮助（其中几篇也是Derek写的[还有一篇是我写的]）。
z9ju0rcb2#
首先，熟悉http://en.wikipedia.org/wiki/Flow-based_programming和http://en.wikipedia.org/wiki/Dataflow_programming。参与者模型是数据流编程的子集，参与者模型的实现甚至受到更多的限制。
7qhs6swi3#
我只是对一个类似的问题给出了一个more elaborate answer，但我将在这里总结我发现的关于Actor模型的最有趣的资源。
设计模式：
被动参与者和DDD：
原型演员（由Akka的创作者之一的项目与Alexey Zimarev的帮助）。我发现这个项目比Akka更容易理解，这是非常复杂的（我没有隶属于他们，但考虑使用）：
然后搜索Github actor-model主题可能会得到有趣的东西。
我在QCon视频Actors or Not: Async Event Architectures中找到了更多的书籍推荐：
9lowa7mx4#
我找到了更多关于基于事件编程的文献。
http://www.amazon.com/Event-Based-Programming-Taking-Events-Limit/dp/1590596439/ref=pd_rhf_ee_s_cp_8
关于基于事件的交互模式的章节看起来很有希望
vom3gejh5#
这里值得一提的是企业集成模式（http://www.eaipatterns.com/）的工作。在他们的工作中完全有可能从来没有提到过“actor”这个词，但是从队列处理器到actor的翻译是微不足道的，就像将Poe从英语翻译成法语一样。像你描述的负载平衡模式是你在那里学到的最少的东西。