Erlang / OTP：同步与异步消息传递 [英] Erlang/OTP: Synchronous vs. Asynchronous messaging

问题描述

首先吸引我到Erlang的一件事是Actor模型；

One of the things that attracted me to Erlang in the first place is the Actor model; the idea that different processes run concurrently and interact via asynchronous messaging.

我刚刚开始涉足OTP，尤其是研究gen_server。我看过的所有示例（当然都是教程类型的示例），都使用 handle_call（）而不是 handle_cast（）实施模块行为。

I'm just starting to get my teeth into OTP and in particular looking at gen_server. All the examples I've seen - and granted they are tutorial type examples - use handle_call() rather than handle_cast() to implement module behaviour.

我发现这有点令人困惑。据我所知， handle_call 是一个同步操作：调用者被阻塞，直到被调用者完成并返回为止。

I find that a little confusing. As far as I can tell, handle_call is a synchronous operation: the caller is blocked until the callee completes and returns. Which seems to run counter to the async message passing philosophy.

我将要启动一个新的OTP应用程序。这似乎是一项基本的体系结构决策，所以我想确保在上船之前理解。

I'm about to start a new OTP application. This seems like a fundamental architectural decision so I want to be sure I understand before embarking.

我的问题是：

1. 实际上，人们倾向于使用 handle_call 而不是 handle_cast 吗？
   
2. 如果是这样，当多个客户端可以调用同一进程/模块时，对可伸缩性有何影响？

1. In real practice do people tend to use handle_call rather than handle_cast?
2. If so, what's the scalability impact when multiple clients can call the same process/module?

推荐答案

1. 取决于您的情况。

1. Depends on your situation.

如果要获得结果，请 handle_call 确实很常见。如果您对通话结果不感兴趣，请使用 handle_cast 。当使用 handle_call 时，呼叫者将阻止，是的。大部分时间都可以。让我们看一个例子。

If you want to get a result, handle_call is really common. If you're not interested in the result of the call, use handle_cast. When handle_call is used, the caller will block, yes. This is most of time okay. Let's take a look at an example.

如果您有一个网络服务器，可以将文件内容返回给客户端，则可以处理多个客户端。每个客户端必须等待读取文件的内容，因此在这种情况下使用 handle_call 会很好（除了愚蠢的示例）

If you have a web server, that returns contents of files to clients, you'll be able to handle multiple clients. Each client have to wait for the contents of files to be read, so using handle_call in such a scenario would be perfectly fine (stupid example aside).

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

When you really need the behavior of sending a request, doing some other processing and then getting the reply later, typically two calls are used (for example, one cast and the one call to get the result) or normal message passing. But this is a fairly rare case.

使用 handle_call 会在呼叫。这将导致客户排队等待他们的答复，因此整个过程将按顺序运行。

Using handle_call will block the process for the duration of the call. This will lead to clients queuing up to get their replies and thus the whole thing will run in sequence.

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

If you want parallel code, you have to write parallel code. The only way to do that is to run multiple processes.

因此，总结一下：

• 使用 handle_call 将阻塞呼叫者并占用整个呼叫过程中被呼叫的进程。


• 如果要继续进行并行活动，则必须并行化。唯一的方法是启动更多的进程，突然之间，调用vs强制转换不再是一个大问题了（实际上，调用更加舒适）。

• Using handle_call will block the caller and occupy the process called for the duration of the call.
• If you want parallel activities to go on, you have to parallelize. The only way to do that is by starting more processes, and suddenly call vs cast is not such a big issue any more (in fact, it's more comfortable with call).

这篇关于Erlang / OTP：同步与异步消息传递的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！