rpc:call/4函数解析

2019独角兽企业重金招聘Python工程师标准>>>

最近听说erlang的rpc跟其他语言的rpc模式不是很相同，所以就开始学习rpc模块的方法，以下是rpc:call/4函数的一些解析。

rpc:call/4函数体：

call(N,M,F,A) when node() =:= N ->  %% Optimize local call
    local_call(M, F, A);
call(N,M,F,A) ->
    do_call(N, {call,M,F,A,group_leader()}, infinity).

这里会判断是否是在当前节点内运行。如果是的话，我们接着往下看：

local_call(M, F, A) when is_atom(M), is_atom(F), is_list(A) ->
    case catch apply(M, F, A) of
	{'EXIT',_}=V -> {badrpc, V};
	Other -> Other
    end.

则直接调用apply方法，得到结果。

如果不是当前节点：

do_call(Node, Request, infinity) ->
    rpc_check(catch gen_server:call({?NAME,Node}, Request, infinity));
do_call(Node, Request, Timeout) ->
    Tag = make_ref(),
    {Receiver,Mref} =
	erlang:spawn_monitor(
	  fun() ->
		  %% Middleman process. Should be unsensitive to regular
		  %% exit signals.
		  process_flag(trap_exit, true),
		  Result = gen_server:call({?NAME,Node}, Request, Timeout),
		  exit({self(),Tag,Result})
	  end),
    receive
	{'DOWN',Mref,_,_,{Receiver,Tag,Result}} ->
	    rpc_check(Result);
	{'DOWN',Mref,_,_,Reason} ->
	    %% The middleman code failed. Or someone did 
	    %% exit(_, kill) on the middleman process => Reason==killed
	    rpc_check_t({'EXIT',Reason})
    end.

rpc_check({'EXIT', {{nodedown,_},_}}) ->
    {badrpc, nodedown};
rpc_check({'EXIT', _}=Exit) ->
    %% Should only happen if the rex process on the other node
    %% died.
    {badrpc, Exit};
rpc_check(X) -> X.

这里会另外启动一个进程处理rpc要处理的内容，使用gen_server:call/3方法。要注意，这里有超时情况的考虑，如果是infinity则永远等待；如果是Timeout时间，则spawn_monitor新进程，关注新进程的返回值。通过exit/1来返回值，这里也是一种比较特别的返回值的方式。为什么2个超时时间不同而采取不同的处理方式，这里面不是很明白。翻看了一下gen_server:call/4的实现代码，对不同的timeout进行相同的处理，这里看起来有些冗余。最后所有的方法都要检查返回值。

gen_server:call/3方法调用{?NAME, Node}进程来处理，我们可以看到rpc.erl就是一个gen_server实现的模块，rpc模块启动的进程名称就是?NAME.

-define(NAME, rex).

-behaviour(gen_server).


start() ->
    gen_server:start({local,?NAME}, ?MODULE, [], []).

start_link() ->
    gen_server:start_link({local,?NAME}, ?MODULE, [], []).

接下来，我们看handle_call处理：

handle_call({call, Mod, Fun, Args, Gleader}, To, S) ->
    handle_call_call(Mod, Fun, Args, Gleader, To, S);


handle_call_call(Mod, Fun, Args, Gleader, To, S) ->
    %% Spawn not to block the rpc server.
    {Caller,_} =
	erlang:spawn_monitor(
	  fun () ->
		  set_group_leader(Gleader),
		  Reply = 
		      %% in case some sucker rex'es 
		      %% something that throws
		      case catch apply(Mod, Fun, Args) of
			  {'EXIT', _} = Exit ->
			      {badrpc, Exit};
			  Result ->
			      Result
		      end,
		  gen_server:reply(To, Reply)
	  end),
    {noreply, maps:put(Caller, To, S)}.

为了不阻塞rpc这个进程的运行，新spawn_monitor启动一个进程处理。这里要设置group_leader，主要是把io输出给集中到一起，这个可以另外参考：

[Erlang 0041] 详解io:format

group_leader的设计和用途

这里新启动的进程崩溃掉，rpc进程会收到通知：

handle_info({'DOWN', _, process, Caller, normal}, S) ->
    {noreply, maps:remove(Caller, S)};
handle_info({'DOWN', _, process, Caller, Reason}, S) ->
    case maps:get(Caller, S, undefined) of
	undefined ->
	    {noreply, S};
	{_, _} = To ->
	    gen_server:reply(To, {badrpc, {'EXIT', Reason}}),
	    {noreply, maps:remove(Caller, S)}
    end;

确保前面调用rpc:call/4的进程能收到返回错误的信息。

总的来说，rpc:call/4的操作就是，如果是本节点内的rpc操作，则直接运行；如果不是本节点，则发送要运行的命令指令到指定的节点中的?NAME进程进行处理。？NAME进程基于不阻塞的考虑，会另外启动新进程进行处理。但总的来说，如果rpc:call/4操作很频繁的话，还是会出现？NAME进程响应不过来的情况，存在单点故障的情况。

转载于:https://my.oschina.net/u/191928/blog/739802