消息的时间顺序
阅读（略读足以进行编码）Erlang 编程和Erlang 编程。
有一个问题，听起来很简单：
如果机器 m1 上有一个进程 Pid1，并且有十亿条消息发送到 Pid1 ，消息是否由该进程并行处理（我的印象是否）和（下面回答）
处理消息时是否有任何顺序保证？ IE。按发送顺序收到？如果是这样，在高流量情况下如何处理时钟偏差以进行排序？
来自整个 C/线程池/共享状态背景......我想得到具体的信息。我了解分发应用程序，但希望在构建流程和分发工作负载之前确保“原始骨架”符合我的预期。
另外，我的想法是否正确，全世界都在浏览 Erlang 文本；）
Read (skimmed enough to get coding) through Erlang Programming and Programming Erlang.
One question, which is as simple as it sounds:
If you have a process Pid1 on machine m1 and a billion million messages are sent to Pid1, are messages handled in parallel by that process (I get the impression no) and(answered below)
is there any guarantee of order when processing messages? ie. Received in order sent? If so, how is clock skew handled in high traffic situations for ordering?
Coming from the whole C/Thread pools/Shared State background ... I want to get this concrete. I understand distributing an application, but want to ensure the 'raw bones' are what I expect before building processes and distributing workload.
Also, am I right in thinking the whole world is currently flicking through Erlang texts ;)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果进程 A 向进程 B 发送两条消息，则保证这两条消息按发送顺序到达。
如果进程 A 向进程 B 发送一条消息，然后向进程 C 发送一条消息，则无法保证它们的接收顺序。
类似地，如果进程A& B 向 C 发送消息，无法保证消息接收的顺序。
这是消息传递模型的基本属性，不同进程中的计算顺序是未定义的，您只能有意义地谈论涉及消息发送的顺序。上述规则的一个结果是，如果 A 向 C 发送一条消息，然后向 B 发送一条消息，并且在收到 B 向 C 发送的消息后，则 C 可以按任何顺序接收这两条消息。 （实际上，我怀疑这在单个节点上永远不会逆转，但如果三个进程位于不同的节点上，则很容易发生。）
If process A sends two messages to process B, then the two messages are guaranteed to arrive in the order they are sent.
If process A sends a message to process B and then a message to process C, there's no guarantee as to the ordering in which they are received.
Similarly, if processes A & B send messages to C, there's no guarantee as to the order in which the messages are received.
It's a fundamental property of the message passing model the ordering of calculations in different processes is undefined, you can only meaningfully speak about ordering where a message send is involved. One consequence of the above rules is that if A sends a message to C, then a message to B, and on receipt of the message B sends to C, then C can receive the two messages in any order. (In practice, I suspect this never reverses on a single node, but could easily happen if the three processes are on different nodes.)
消息不是并行处理的；毕竟这只是一个过程。
至于消息排序：消息队列按“时间顺序”（从最旧到最新）扫描。我想我记得很久以前的一个邮件列表讨论，其中有人澄清时间戳是消息起源的时间戳（即发送的时间），但我不记得了太清楚了，我在网上找不到任何参考资料。
请注意，您的
receive语句可以对传入消息队列的头部执行匹配，这当然将允许接收者不按（时间）顺序挑选传入消息。Messages are not handled in parallel; it's just one process, after all.
As to messaged ordering: the message queue is scanned in "time order" (oldest to newest). I think I recall a mailing list discussion a long time ago wherein somebody clarified that the timestamp is that of the messages origination (that is, the time at which it was sent), but I can't remember too clearly and I can't find any references to that online.
Note that your
receivestatement can perform matching on the head of the incoming message queue, which of course would allow a receiver to pick off incoming messages out of (temporal) order.根据 erlang 参考手册：
每个进程都会串行处理消息。
Per the erlang reference manual:
Messages are processed serially per process.