在Erlang中提供强大的消息传递

Question

这与我之前的问题

中正在进行的讨论有关

performance penalty of message passing as opposed to shared data

正在讨论的问题之一是使用消息传递与共享状态在Erlang中分布式算法所需的工作量。我的观点是，使用共享状态（可能是数据库中的记录）实现分布式领导者选举比设计对消息丢失具有鲁棒性的算法更容易。不是吗？

实现基于消息传递的算法的问题在于，我们必须使分布式算法对消息丢失具有鲁棒性，或者以某种方式确保即使需要多次尝试也始终传递消息。当然，分布式领导者选举是一个众所周知的问题，我认为已经存在一个强大的消息传递算法（可能是nancy lynch的书给出的），但我只是以此问题为例来推动一个观点。

谢谢！

Answer 1

  

邮件发送是异步且安全的，只要收件人存在，邮件就可以保证最终到达收件人。

如果进程终止，将向所有链接的进程发出退出信号。

在分布式环境中，您甚至可以使用erlang：monitor_node / 2来监视节点的状态。来自文档，

  

如果与它的连接丢失，则会收到消息{nodedown，Node}。

IMO，您需要做的就是处理连接丢失。

Answer 2

生活中的许多事情都取决于它。

这取决于我们在这里讨论的比例。您的共享状态有哪些特征？如果它是SPOF（“单点故障”），那么您将面临容错问题以及可能的访问问题（带宽，处理）。

如果我们正在讨论一个对容错较少关注的小规模系统，那么可以更容易地使用中央数据库。

然后，我对这个问题感到有点困惑：消息传递涉及通信方面，而数据库则用于处理存储方面。为什么我会在你的问题中得到这些东西混淆的印象？ （当然可能只是我）。

---

On Message Passing robustness：这里的问题到底是什么？作为TCP的通信层有很多帮助，尽管在这个地球上任何东西都不完美。如果您担心节点之间通信的整体复杂性，那么无论您选择何种平台/语言，都不会消失。 Erlang只是让分布式通信更容易。

Answer 3

我认为你在问题/讨论中做了一些奇怪的假设。您接受消息可以消失，但使用共享状态将始终有效并且永不失败，然后您尝试比较算法的复杂性。它不像那样工作。当出现问题时，他们会这样做，但是他们会按程序编程。使用可变共享状态来构建并发系统很困难，使用它来构建健壮的并发系统是一个正确的混蛋。

在任何真正的分布式系统中，如果您想确保它是健壮的，您将始终必须考虑到消息可能无法到达。具体如何完成取决于应用程序。

Answer 4

从你说“实施的问题......”，你有一个重言式。

无论您是使用消息传递还是共享状态实现算法，您的代码都必须处理失败才能保持健壮。无论如何你都不能理会错误处理，但是你的代码根据定义并不健全。如果你说“Erlang必须这样做才能变得健壮”，然后说“但我可以在数据库中更新一行并且它总能工作”，那么你就不会比较苹果和苹果。在任何情况下，关于数据库（或共享状态）的声明总是在第一次尝试时工作显然是错误的。

因此，要使用消息传递实现，您需要一个API将消息传递结构封装到足够高的级别，以便它适合您的应用程序编程人员使用，但仍需由他们来检查和处理故障

归结为此（这就是为什么我说这是一个重言式）：

a）如果使用消息传递，您的代码必须实现“消息传递成功或您收到错误（超时）”。

b）如果使用数据库，那么您的代码必须实现“行已成功更新，否则您将收到错误”。 （这同样适用于任何共享状态解决方案）。

由于a和b是等价的，所以你所谈到的“问题”同样适用于消息传递和数据库方法，因此没有太多要讨论的内容。

现在哪个更简单（或更合适），没有简单的答案。明智的答案是“使用适合您的问题领域的任何方法”。在谈论Erlang时，您还应该考虑使用哪些库/工具，例如OTP，因为它们会对您实现这些内容的方式产生巨大影响。