想象一下，我们遇到以下问题：
基本上，我们有一个逻辑实体，为了参数，我们将调用“作业队列”。 每个作业队列都包含多个（异构）进程。一个实现实际队列并始终可用（不阻止）的队列。一个管理工人机器的人。我们还有几个（按需生成）工作者，它们从队列中取出条目，尝试将它们发送到工作机器，解决错误;也许返回（不成功）尝试队列（要重试）等等。我们也可能有一个“经理”过程来协调上面的工作。我们有很多“工作队列”，他们都包含很多流程。
注意：这可能不是解决这个问题的完美解决方案，但我们假设它是。我的问题不是如何解决问题，而是如何管理代表逻辑实体的流程的“组”。
那么，你如何在OTP中代表这一点？你有多少监管树，你在“工作队列”实体之间共享主管，或者你是否有每个逻辑实体的主管。 另外，你如何管理整个事情。
我有一个猜测，但这是一个非常棘手的问题（因为我已经尝试过以几种不同的方式实现它），所以我不会分享我的（也许不是那么糟糕）的想法（现在）。
答案 0 :(得分：1)
我会为每个逻辑组件使用专用的主管（我猜你的意思是逻辑：http-workers，manager，dispatchers）。其中每个人都会在其中一个班级担任主管。 我喜欢它，因为我可以从控制它的其他工具中受益（计算孩子，在i（）中查看它等）并且它很好地将系统分开。
@MinimeDJ提到的Gproc和sync / async是完全不同的东西。
我认为如果你需要在你描述的系统中使用gproc，它不是最好的架构。 重新设计它以尽可能多地建立无状态层。例如。而不是维护调度员=推模型，尝试拉模型=从后端机器拉任务。这个解决方案使队列无状态，你摆脱调度员，如果出现任何问题，后端层将任务再次放入某个队列。 此外，管理员只是简化为队列和一些统计收集器的API。后端工作负载在每个异构后端模块中进行测量和控制（localy！）。
答案 1 :(得分：0)
从上面我们还有一个由许多特殊块组成的系统，我们的第一个架构与你的类似。我们使用RabbitMQ而不是HTTP，我相信在消息交换方面更方便。
但在最终版本发布之前，我们理解维护整个系统的生产将是一项真正的挑战。
所以，我们再次重新设计了它。现在我们将每个逻辑块表示为进程gen_server。每个进程都有一个唯一的名称，并存在于gproc中。由于gproc可以存在于许多节点上，因此我们可以很容易地管理容错系统。
所以，我想说，我们有可管理对象模型（我们称之为MOM，因为我们非常喜欢它）。
所以，对我来说，你的系统似乎过于复杂。我不知道我的答案是否有用，但有时值得以一种你从未想到的方式考虑你的系统。我希望你能找到一种方法来轻松管理它。