这与我之前的问题中正在进行的讨论有关
正在讨论的问题之一是在 Erlang 中使用消息传递与共享状态的分布式算法所需的工作量。我的观点是，使用共享状态（可能是数据库中的记录）实现分布式领导选举比设计一种对消息丢失具有鲁棒性的算法更容易。不是吗？
实现基于消息传递的算法的问题在于，我们必须使分布式算法对消息丢失具有鲁棒性，或者以某种方式确保即使需要多次尝试也始终传递消息。当然，分布式领导选举是一个众所周知的问题，我认为已经存在一个健壮的消息传递算法（可能是 nancy lynch 的书给出的），但我只是以这个问题为例来说明一下。
谢谢！
消息发送是异步且安全的，只要接收者存在，就保证消息最终到达接收者。
如果一个进程死亡，一个退出信号将被发送到所有链接的进程。
在分布式环境中，您甚至可以使用 erlang:monitor_node/2 来监控节点的状态。从文档中，
如果与它的连接丢失，则会收到一条消息{nodedown, Node}。
IMO，您需要做的就是处理连接丢失。
生活中的许多事情：这取决于。
这取决于我们在这里谈论的规模。你的共享状态有什么特点？如果它是 SPOF（“单点故障”），那么您将面临容错问题以及可能的访问问题（带宽、处理）。
如果我们谈论的是对容错性关注较少的小规模系统，那么是的，使用中央数据库可能更容易。
再说一次，我对这个问题有点困惑：消息传递处理通信方面，而数据库用于处理存储方面。为什么我觉得这些东西在你的问题中混在一起了？（当然可能只有我）。
关于消息传递的稳健性：这里真正的问题是什么？TCP 的通信层有很大帮助，尽管它不像地球上的任何东西一样不完美。如果您担心节点之间通信的整体复杂性，那么无论您选择哪种平台/语言，这都不会消失。Erlang 只是让分布式通信更容易。
我认为您在问题/讨论中做出了一些奇怪的假设。您接受消息可能会消失，但使用共享状态将始终有效且永远不会失败，然后您尝试比较算法的复杂性。它不是那样工作的。当事情出错时，他们会这样做，但他们会按照程序进行。使用可变共享状态来构建并发系统是困难的，用它来构建健壮的并发系统是一个正确的混蛋。
在任何真正的分布式系统中，如果你想确保它是健壮的，你总是必须考虑到消息可能不会到达。具体如何完成取决于应用程序。
从你说“实施的问题......”的地方，你有一个重言式。
无论您是使用消息传递还是共享状态来实现您的算法，您的代码都必须处理故障以保持稳健。无论如何，您不必费心处理错误，但是根据定义，您的代码并不健壮。如果你说“Erlang 必须做某事才能变得健壮”，然后说“但我可以更新数据库中的一行并且它总是可以工作”，那么你并不是在比较苹果和苹果。在任何情况下，关于数据库（或共享状态）总是在第一次尝试时工作的陈述显然是错误的。
因此，要使用消息传递来实现，您需要一个 API 将消息传递结构包装到足够高的级别，以便适合您的应用程序程序员使用，但仍然由他们来检查和处理故障。
归结为这一点（这就是为什么我说它是重言式）：
a) 如果使用消息传递，您的代码必须实现“消息传递成功或出现错误（超时）”。
b) 如果使用数据库，那么您的代码必须实现“行已成功更新，否则会出错”。（这同样适用于任何共享状态解决方案）。
由于 a 和 b 是等价的，因此您谈论的“问题”同样适用于消息传递和您的数据库方法，因此没有太多要讨论的内容。
现在关于哪个更容易（甚至更合适）没有简单的答案。明智的答案是“使用更适合您的问题领域的任何方法”。在谈论 Erlang 时，您还应该考虑您正在使用哪些库/工具，例如 OTP，因为它们会对您如何实现这些东西产生巨大影响。