您如何在 OTP 中表示多进程逻辑实体？

Question

假设我们有以下问题：

1. 我们有执行对我们软件的请求的 http 客户端。因此，我们有一个始终可供他们使用的进程，并将他们的请求存储在一个队列中。
2. 我们需要将这些请求分派到我们内部网络中的一台机器上（同样通过 HTTP）。
3. 这种机器并不总是可用的。它由我们的软件按需启动（并在队列为空时停止）（再次向“管理器”机器发出 HTTP 请求）。
4. 我们有几个（或很多）上述情况。

所以基本上，我们有一个逻辑实体，为了便于论证，我们将其称为“作业队列”。 每个作业队列都由几个（异构）进程组成。一种实现实际队列并且始终可用（不阻塞）的方法。管理工作机器的一种。我们还有几个（按需生成的）worker，它们从队列中取出条目，尝试将它们发送到worker机器，解决错误；可能会返回（不成功）尝试到队列（将被重试）等。而且我们可能还有一个“管理器”进程来协调上述工作。而且我们有很多“作业队列”，它们都由很多进程组成。

注意：这可能不是这个确切问题的完美解决方案，但让我们假设它是。我的问题不是关于如何解决问题，而是如何管理代表逻辑实体的此类进程“组”。

那么，您如何在 OTP 中表示这一点？您有多少监督树，您是否在“作业队列”实体之间共享监督者，或者每个逻辑实体都有一个监督者。 另外，您如何管理整个事情。

我有一个猜测，但这是一个相当棘手的问题（因为我已经尝试以几种不同的方式实现它），所以我不会（现在）分享我的（也许不是那么糟糕）的想法。

Answer 1

我会为每个逻辑组件使用专门的主管（我猜你的意思是逻辑：http-workers、manager、dispatchers）。这些人中的每一个都会对其中一个班级进行监督。 我喜欢它，因为我可以从其他控制它的工具中受益（计算孩子，在 i() 中查看它等），并且它很好地分离了系统。

@MinimeDJ 提到的 Gproc 和同步/异步的东西是完全不同的东西。

如果您需要在您描述的系统中使用 gproc，我认为这不是最好的架构。 重新设计它以拥有尽可能多的无状态层。例如。与其维护调度程序 = 推模型，不如尝试拉模型 = 从后端机器拉任务。该解决方案使队列无状态，您可以摆脱调度程序，如果出现任何问题，后端层会将任务再次放入某个队列中。 此外，管理器只是简化为用于队列和一些统计收集器的 API。在每个异构后端模块中测量和控制（本地！）后端工作人员的负载。

Answer 2

从上面我们也有一个由许多特殊块组成的系统，我们的第一个架构与您的类似。我们使用 RabbitMQ 而不是 HTTP，我认为它在消息交换方面更方便。

但在最终版本发布之前，我们明白在生产中维护整个系统将是一个真正的挑战。

因此，我们再次对其进行了重新设计。现在我们将每个逻辑块表示为一个进程gen_server。每个进程都有一个唯一的名称并存在于 gproc 中。由于 gproc 可以存在于许多节点上，因此我们非常容易管理容错系统。

所以，我想说，我们有可管理的对象模型（我们称它为 MOM，因为我们真的很喜欢它）。

所以，对我来说，您的系统似乎过于复杂。我不知道我的回答是否有用，但有时值得以你一开始没想到的方式思考你的系统。我希望你能找到一种简单的方法来管理它。