rpc:call函数解析

起因：

　　 由于业务需求，有时候临时统计数据和查看服务器状态需要向所有运行的ERLANG结点获取数据。昨天遇到一个奇葩的问题，在通过一个ERLANG中心结点向其相连的结点进行rpc:call/4来远程执行一个Func的时出现了大量的超时错误，尝试着给rpc:call加上TimeOut，一直加到100000发现超时问题还存在。为了解决这个问题，因此对rpc:call的实现方式进行了一定的探究。

过程：　

　先看调用rpc:call的代码：

　　rp([begin rpc:call(Node,Mod,Func,[Arg]) end || Node <- nodes([hidden]),string:str(common_tool:to_list(Node),TargtNode) =:= 1]).这里的ARG实际上传入的是一个需要执行的Func，mod和func是一个运行函数的call方法的封装。

　　将rpc:call(Node,?MOD,?FUNC,[?ARG]) 换成rpc:call(Node,?MOD,?FUNC,[?ARG],Timeout)之后超时问题依旧存在。

　　开始纠结rpc:call的实现方式，通过读文档和源码可以得知下面的概念：

　　　　1、rpc:call/4其实相当于rpc:call(Node,?MOD,?FUNC,[?ARG],infinity)，就是说call/4是不带有超时控制的，可见我上面的问题不是出现在rpc:call这一边。

　　　　2、使用Timeout字段其实会代码非常大的性能损耗，原因是在rpc模块，带有Timeout的调用会会在rpc模块就额外的创建一个中间进程来实现超时控制和数据返回，这样的好处就是超市以后收到的消息不会污染调用者进程的信箱。

　　　　3、rpc:call/4和rpc:call/5其实本质上都是调用到了gen_server:call/3，这里的特殊点是：这里的目标进程是{?NAME,Node}，进入gen_server模块之后，加上'$gen_call'参数后继续向下调用，传递到gen模块

　　　　4、到了gen模块后，首先调用erlang:monitor(process, Process)函数来确定目标进程或者是结点的存活状态，而实际上数据发送是通过erlang:send(Process, {Label, {self(), Mref}, Request},[noconnect])来实现的。在发送完消息后，就进入了receive的阻塞状态，实际上在gen模块的阻塞状态中依旧有超时控制。这样一个带有Timeout的rpc:call/5其实会因为receive而阻塞两次，同时还会创建一个新的中间进程，其目的是为了防止call长时间超时带来的进程阻塞危害。

 

　　这样下来问题依旧还未解决，超时问题不是出现在本地结点的，那么就应该在远程结点。对传入的mod和func进行追踪发现，其本身带有一个4秒的超时，问题发现！！！

 

解决方案：抛弃掉采用在某个模块调用call方法来执行func的办法，采用erlang:apply/2来执行，摒弃掉超时控制。

　　　　　于此同时在结点数量过多的时候上面的顺序执行的办法会使得整体的调用速度很慢，既然对每个结点的call都可以算作是并行的，于是改进上面的函数为

[begin erlang:spawn(fun() ->io:format("~w~n",[rpc:call(Node,erlang,apply,[?Func,[]])]) end),[]end || Node <- nodes([hidden]),string:str(common_tool:to_list(Node),TargtNode) =:= 1].

 

结果：采用上述方法后，对多节点的访问速度有了非常大的提升，但是在shell输出端多了进程Pid的List输出，此时的本法可以在后面加上,[].来让输出更为清晰。