Erlang/OTP：同步与异步消息传递

Question

Erlang 最初吸引我的地方之一就是 Actor 模型；不同进程同时运行并通过异步消息传递进行交互的想法。

我刚刚开始接触 OTP，特别是关注 gen_server。我见过的所有示例 - 并且假定它们是教程类型的示例 - 使用 handle_call() 而不是 handle_cast() 来实现模块行为。

我觉得这有点令人困惑。据我所知，handle_call 是一个同步操作：调用者被阻塞，直到被调用者完成并返回。这似乎与异步消息传递哲学背道而驰。

我即将开始新的 OTP 申请。这似乎是一个基本的架构决策，所以我想在开始之前确保我理解。

我的问题是：

1. 在实际实践中，人们是否倾向于使用 handle_call 而不是 handle_cast？
2. 如果是这样，当多个客户端可以调用相同的进程/模块时，可扩展性有何影响？

Answer 1

1. 取决于您的情况。

   如果你想得到结果，handle_call确实很常见。如果您对调用结果不感兴趣，请使用handle_cast。当使用handle_call时，调用者会阻塞，是的。这大部分时间都可以。让我们看一个例子。

   如果您有一个将文件内容返回给客户端的 Web 服务器，您将能够处理多个客户端。每个客户端必须等待读取文件内容，因此在这种情况下使用handle_call就完全没问题（除了愚蠢的例子）。

   当您确实需要发送请求、进行一些其他处理然后稍后获取回复的行为时，通常会使用两个调用（例如，一个强制转换和一个调用来获取结果）或正常的消息传递。但这是相当罕见的情况。

2. 使用handle_call将在调用期间阻塞进程。这将导致客户端排队等待回复，因此整个过程将按顺序运行。

   如果你想要并行代码，你就必须编写并行代码。唯一的方法是运行多个进程。

因此，总结一下：

• 使用handle_call将阻塞调用者并在调用期间占用被调用的进程。
• 如果您希望并行活动继续进行，则必须并行化。唯一的方法是启动更多进程，突然之间 call 与cast 不再是一个大问题（事实上，call 更舒服）。

Answer 2

Adam的回答很好，但我有一点要补充

<块引用>

使用handle_call将在调用期间阻塞进程。

对于发出handle_call 调用的客户端始终如此。这花了我一段时间来思考，但这并不一定意味着 gen_server 在应答 handle_call 时也必须阻塞。

就我而言，当我创建一个处理 gen_server 的数据库并故意编写一个执行 SELECT pg_sleep(10) 的查询时遇到了这种情况，这是 PostgreSQL 所说的“睡眠 10 秒”，并且是我的测试非常昂贵的查询的方法。我的挑战：我不希望数据库 gen_server 坐在那里等待数据库完成！

我的解决方案是使用 gen_server:reply/2：

<块引用>

当无法在 Module:handle_call/ 的返回值中定义回复时，gen_server 可以使用此函数显式向调用 call/2,3 或 multi_call/2,3,4 的客户端发送回复3.

在代码中：

-module(database_server).
-behaviour(gen_server).
-define(DB_TIMEOUT, 30000).

<snip>

get_very_expensive_document(DocumentId) ->
    gen_server:call(?MODULE, {get_very_expensive_document, DocumentId}, ?DB_TIMEOUT).    

<snip>

handle_call({get_very_expensive_document, DocumentId}, From, State) ->     
    %% Spawn a new process to perform the query.  Give it From,
    %% which is the PID of the caller.
    proc_lib:spawn_link(?MODULE, query_get_very_expensive_document, [From, DocumentId]),    

    %% This gen_server process couldn't care less about the query
    %% any more!  It's up to the spawned process now.
    {noreply, State};        

<snip>

query_get_very_expensive_document(From, DocumentId) ->
    %% Reference: http://www.erlang.org/doc/man/proc_lib.html#init_ack-1
    proc_lib:init_ack(ok),

    Result = query(pgsql_pool, "SELECT pg_sleep(10);", []),
    gen_server:reply(From, {return_query, ok, Result}).

Answer 3

IMO，在并发世界中 handle_call 通常是一个坏主意。假设我们有进程 A (gen_server) 接收一些事件（用户按下按钮），然后将消息传递给进程 B (gen_server)，请求对按下的按钮进行大量处理。进程 B 可以生成子进程 C，后者在准备好时将消息投射回 A（然后将消息投射回 A）。在处理期间，A 和 B 都准备好接受新请求。例如，当 A 收到来自 C（或 B）的投射消息时，它会向用户显示结果。当然，第二个按钮可能会在第一个按钮之前被处理，因此 A 可能应该以正确的顺序累积结果。通过handle_call阻塞A和B将使该系统成为单线程（尽管会解决排序问题）。

事实上，生成C与handle_call类似，不同的是C是高度专业化，仅处理“一条消息”，然后退出。 B 应该具有其他功能（例如限制工作人员数量、控制超时），否则可以从 A 生成 C。

编辑：C 也是异步的，因此生成 C 它与 handle_call 不相似（ B 未被阻止）。

Answer 4

有两种方法可以解决这个问题。一是改用事件管理方法。我正在使用的方法是使用如图所示的强制转换...

    submit(ResourceId,Query) ->
      %%
      %% non blocking query submission
      %%
      Ref = make_ref(),
      From = {self(),Ref},
      gen_server:cast(ResourceId,{submit,From,Query}),
      {ok,Ref}.

强制转换/提交代码是...

    handle_cast({submit,{Pid,Ref},Query},State) ->
      Result = process_query(Query,State),
      gen_server:cast(Pid,{query_result,Ref,Result});

该引用用于异步跟踪查询。