理解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的監督職責

回答

相關問題