今天在写项目时需要用到 Erlang 的多层监督机制,写过程中遇到点问题,再此记录下来,也希望对正在学习 Erlang 的小伙伴有帮助。
Erlang 支持多重监督机制。otp design 上面有详细的介绍。
大致样子如下图:
途中方块表示督程(supervisor),圆圈表示拥程(worker)。本篇文章从头到尾会建立一个上图所示的监督树。
开始我们先用 rebar 简单的建立个项目
rebar create-app appid=one
名称为 one,这也就是说我们最顶层的督程为 one_sup。
建立完成后会产生一下 3 个文件:
one_app.erl
one.app.src
one_sup.erl
先放这里:)
建立督程 one_sup:
one_sup.erl
文件如下,使用 rebar
建立会有默认模板,为代码的简洁性我就去掉了:)
-module(one_sup).
-behaviour(supervisor).
-export([start_link/0]).
-export([init/1]).
start_link() ->
supervisor:start_link({local, ?MODULE}, ?MODULE, []).
init([]) ->
{ok, { {one_for_one, 5, 10},
[
%% 子督程
{son_sup, {son_sup, start_link, []},
temporary,
brutal_kill,
supervisor,
[son_sup]
},
%% 子拥程
{son_work, {son_work, start_link, []},
temporary,
brutal_kill,
worker,
[son_work]
}
%% 子拥程2
{son_work2, {son_work, start_link, []},
temporary,
brutal_kill,
worker,
[son_work]
}
]
} }.
start_link
会创建一个 supervisor
督程,创建后init
函数将被调用。init
函数指定了督程两种子进程的类型,一种为 supervisor
,另一种为 worker
。
init
函数内部剩余参数如果不理解戳 Erlang otp Supervisor 行为 。
注意:
start_link() ->
supervisor:start_link({local, ?MODULE}, ?MODULE, []).
这句代码指定了督程的名字为 ?MODULE
模块名,我们只有在确定某个进程唯一时(也就是确保 start_link
只被调用一次时)才能注册名字。否则第二次添加进程会报错 进程已存在。
建立子督程 son_sup:
-module(son_sup).
-behaviour(supervisor).
-export([start_link/0]).
-export([init/1]).
start_link() ->
supervisor:start_link(?MODULE, []).
init([]) ->
{ok, { {simple_one_for_one, 5, 10},
[
{
grandson_work, {grandson_work, start_link, []},
temporary,
brutal_kill,
worker,
[grandson_work]
}
]
} }.
start_link
函数建立子督程,并指定该督程的子进程是 worker
拥程。
simple_one_for_one
表明我们必须手动添加(通过 start_child
)该进程的子进程。
建立子拥程 son_work:
-module(son_work).
-behaviour(gen_server).
-define(SERVER, ?MODULE).
-export([start_link/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
terminate/2, code_change/3]).
start_link() ->
io:format("我是子拥程~p~n", [self()]),
gen_server:start_link(?MODULE, [], []).
init(Args) ->
{ok, Args}.
handle_call(_Request, _From, State) ->
{reply, ok, State}.
handle_cast(_Msg, State) ->
{noreply, State}.
handle_info(_Info, State) ->
{noreply, State}.
terminate(_Reason, _State) ->
ok.
code_change(_OldVsn, State, _Extra) ->
{ok, State}.
如果你是通过 rebar
构建项目的话,这里的代码命令就可生成。
rebar create template=simplesrv srvid=son_work
子拥程 son_work
是一个 gen_server
。
建立子督程的拥程 grandson_work:
都是 worker
,代码结构与上面大致相同。
-module(grandson_work).
-behaviour(gen_server).
-define(SERVER, ?MODULE).
-export([start_link/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
terminate/2, code_change/3]).
start_link() ->
gen_server:start_link(?MODULE, [], []).
init(Args) ->
{ok, Args}.
handle_call(_Request, _From, State) ->
{reply, ok, State}.
handle_cast(_Msg, State) ->
{noreply, State}.
handle_info(_Info, State) ->
{noreply, State}.
terminate(_Reason, _State) ->
ok.
code_change(_OldVsn, State, _Extra) ->
{ok, State}.
运行观察:
代码分布如下图:
我们来一步一步运行并通过 observer
来观察。
首先,要通过 observer
观察结构图必须构建一个应用 application
,因为 observer
上只能观察应用的进程结构图。
此时监督树如下图所示:
<0.38.0>
和 <0.39.0>
是应用 application_master
创建。
进程状态图:
现在,我们来给 <0.41.0>
子督程添加拥程。
监督树如下图:
到这里基本就完成了,读者可以自行尝试下给 son_sup
再添加一个拥程。就完全如同开篇图片的样子。
总结:
监督机制是 Erlang 的一个重大特性,在细节方面还需要注意一些问题。
比如:
什么情况下用 simple_one_for_one?
督程是否需要命名,拥程呢,什么情况下需要命名?
上图中监督树的第二层拥程可否动态扩展,督程呢,哪个是真正有必要扩展?
以上问题欢迎讨论:)
本文源代码戳 这里