理解Erlang/Elixir的监督职责

我写了一个名为director的新库。
这是一个主管图书馆。
它的一个特点就是给人一种乐趣元数2〜主任，主任会调用函数过程的每一个崩溃，第一个参数是崩溃的原因和第二被碰撞计数，例如：理解Erlang/Elixir的监督职责

-module(director_test). 
-behaviour(director). 
-export([start_link/0, init/1]). 

start_link() -> 
    director:start_link(?MODULE, []). 

init([]) -> 
    ChildSpec = #{id => foo, 
        start => {m, f, args}, 
        plan => [fun my_plan/2], 
        count => infinity}, 
    {ok, [ChildSpec]}. 

my_plan(normal, Count) when Count rem 10 == 0 -> 
    %% If process crashed with reason normal after every 10 times 
    %%, director will restart it after spending 3000 milliseconds. 
    {restart, 3000}; 
my_plan(normal, _Count) -> 
    %% If process crashed with reason normal director will restart its 
    restart; 
my_plan(killed, _Count) -> 
    %% If process was killed, Director will delete it from its children 
    delete; 
my_plan(Reason, Count) -> 
    %% For other reasons, director will crash with reason {foo_crashed, Reason} 
    {stop, {foo_crashed, Reason}}.

我宣布我在斯莱克的图书馆，他们想知道以这种方式写新的主管！有人说：“我倾向于不让主管处理退后”。
最后，他们没有告诉我干净的信息，我想我需要更多地了解监管方和责任等我认为主管是应该明白何时重启删除哪个孩子，当一个过程，孩子何时不重新启动哪个孩子。 对吗？

你能告诉我OTP /主管的一些很好的功能，我在导演有没有关系？（List of director's features）

来源

2017-08-10 Pouriya

通常当有新事物出现时，你的责任是展示你的库中有什么好处，以便我们依赖它而不是使用来自OTP核心的普通旧模式坐在那里从无到有？ – mudasobwa

我做到了这一点（我认为），但问题是，他们导致我认为这是正确的方法，对吗？ – Pouriya

你混合监督和管理的想法。

监督已经是OTP的一部分。它的基本思想是：

没有进程随时可能变成孤儿
崩溃将重新启动或中止，这就是内在的逻辑被写入之前做出的架构决策。
崩溃可以从外部记录（由任何失败以外的进程处理）。
错误处理代码，碰撞取证等不会作为监督的一部分出现。永远。（复杂的逻辑导致了复杂的怪事，监督必须简单，耐用，可靠。）

管理的东西，可能会或可能不会出现在您的系统，因此它留给你。这是一个想法，你会有一个（通常是指定的）过程来指导你的（受监督的）工作人员正在完成的整体高级任务。拥有一个经理流程可以为您完成整体工作提供一个单一的控制点 - 这也意味着它是一个单一的地方，您可以说整体开始，停止，暂停等等的努力，这是您可以添加的地方基于某些崩溃情况的关于选择性重启的附加逻辑。

认为“监督”是一种低层次，系统框架类型的想法。它在所有程序中都一样，就像打开文件或处理网络套接字一样。将管理视为您的程序需要解决以完成其工作的实际问题的一个离散块。

管理层可能会也可能不会很复杂。监督必须始终统一和简单。给主管太多的责任使他们难以理解和调试，并且经常导致业务问题 - 超负荷的主管可能是系统中的主要问题。不要让你的主管承担高层管理任务。

我在Erlang写了一篇关于“service - > worker pattern”的文章。希望它能告诉我们更多的困惑：https://zxq9.com/archives/1311

来源

2017-08-15 12:52:01 zxq9

-2

请不要把这个个人。您要求提供反馈意见，我正在尝试将其提供给您。

后迅速在看文档和代码，我想与你的库中的主要问题是：

你在它通常不需要该地区引入一些复杂性。在绝大多数Erlang程序中，你不想分析一个进程崩溃的原因。分析它很容易出错。所以“正常”解决方案只是重新启动过程。如果您在这一点上引入任何逻辑，您可能也会引入一些错误。这样的方案很难推理，至少有优势是有争议的。
您正在假设退出原因是过程已退出的原因。这不一定是真的。原因可能是从其相关流程中传播出来的。如果你想对所有都有可能的退出原因作出反应，那么你必须对所有进程退出原因进行传递闭包，所有它是子进程退出的原因，他们的所有子进程退出原因等。对于态度非常不好的组件改变，很容易出错。引入的复杂性（见1）爆炸非常严重。
您在理想情况下应该保持内部逻辑的上下文中引入一些“自省”逻辑 - 即对董事会计划中的模块以外使用的过程的内部工作有一些了解。这有点打破封装。 “正常”的主管知道如何启动进程，它不需要关于进程内部的更多信息。
最后但并非最不重要：您可能正在解决一个不存在的问题。您不应该开发一个全新的解决方案，而应该清楚地识别现有解决方案的问题，并尝试非常直接且最低限度地解决问题。

来源

2017-08-14 07:39:02

许多thakns为您的时间，花费只是为了给这个反馈。 – Pouriya

理解Erlang/Elixir的监督职责

回答

相关问题