Erlang：远程调用与发送消息答案

【问题标题】：Erlang: remote call vs sending messagesErlang：远程调用与发送消息
【发布时间】：2012-09-12 13:52:37
【问题描述】：

我想在远程节点上执行一些程序。而且我不确定哪种方法是最好的方法。我可以写一个rpc:call 来做到这一点。或者通过Remote ! {call, some_procedure}向节点发送消息以启动程序并使用receive等待响应。那么在erlang中哪种方式更好？或者它们实际上是为了不同的用途？

【问题讨论】：

用代码示例查看我对答案的编辑。
@stemm 这真的是一个详细的答案。我只是等着看有没有别的观点。

标签： erlang message rpc

【解决方案1】：

最好使用模块rpc，因为如果你不这样做：你必须管理远程节点的监控，必须提供唯一的调用ID，处理超时，你也有为带有函数结果的回送响应提供包装器。

但是所有这些操作都是通用的，并在rpc 模块中实现。

顺便说一下，远程调用有不同的变体，在rpc中实现：同步和异步调用，cast（发送不需要响应的消息），甚至并行地图功能（pmap）。

附言

比较 - 简单地使用 rpc:call 与从头开始实现（另外，这是简单的实现，它不处理一些重要的情况）：

-module(myrpc).
-compile(export_all).

server() ->
        receive
                {{CallerPid, Ref}, {Module, Func, Args}} ->
                        Result = apply(Module, Func, Args),
                        CallerPid ! {Ref, Result}
        end.

call(Node, Module, Func, Args) ->
        monitor_node(Node, true),
        RemotePid = spawn(Node, ?MODULE, server, []),
        Ref = make_ref(),
        RemotePid ! {{self(), Ref}, {Module, Func, Args}},
        receive
                {Ref, Result} ->
                        monitor_node(Node, false),
                        Result;
                {nodedown, Node} ->
                        error
        end.

【讨论】：

考虑到在某些系统中节点监控已经存在，因此编写自己的应用程序感知通信模型并不是那么痛苦。

【解决方案2】：

rpc 似乎是一个综合解决方案，但它在规模方面存在一些缺点。 rpc 使用单个“rex”服务器跨节点通信，可能会不堪重负。如果你使用 rpc，你应该监控这个过程。

如果通信是主要功能并且它是 io/cpu/memory 消费者的顶部，我会考虑自己编写它。另一方面，我们可以期待 OTP 团队的改进（过早的优化是万恶之源！！！）。

【讨论】：