【问题标题】：Erlang clustersErlang 集群
【发布时间】：2012-10-24 02:27:24
【问题描述】：
我正在尝试使用 Erlang 作为将所有这些结合在一起的粘合剂来实现一个集群。我喜欢它创建一个完全连接的节点图的想法，但是在在线阅读不同的文章时，似乎这不能很好地扩展（最多有 50 - 100 个节点）。 OTP 的开发人员是否故意施加此限制？我确实知道您可以将节点设置为仅具有显式连接以及具有隐藏节点等。但是，似乎默认的开箱即用设置不是很有可扩展性。
所以问题：
如果您有 5 个节点（A、B、C、D、E），它们都有明确的连接，例如 A-B-C-D-E。 Erlang/OTP 是否允许 A 直接与 E 对话，或者 A 是否必须将消息从 B 传递到 D 才能到达 E，因此这就是全连接图的原因？同样，这是有道理的，但从我所看到的情况来看，它的扩展性并不好。
如果要尝试使用可扩展且容错的系统，您有哪些选择？似乎，如果由于节点太多而无法创建完全连接的图，那么下一个最好的方法就是创建某种树。但是，这似乎不太容错，因为如果根节点或子节点的任何父节点死亡，您将失去集群的很大一部分。
在研究主管和工作人员时，我看到的所有示例都将此应用于单个节点上的进程。能否应用于节点集群以帮助实现容错？
节点可以是多个集群的一部分吗？
感谢您的帮助，如果有我错过的半近期网站或博文（大约 1 年前），我会很乐意查看这些内容。但是，我已经很好地搜索了互联网。
【问题讨论】：
标签：
erlang
cloud
cluster-computing
distributed-computing
【解决方案1】：
是的，您可以向集群中任何远程节点上的进程发送消息，例如，通过使用其进程标识符 (pid)。这称为位置透明度。是的，它可以很好地扩展（参见 Riak、CouchDB、RabbitMQ 等）。
请注意，一个节点可以运行数十万个进程。 Erlang 已被证明是非常可扩展的，并且是为容错而构建的。还有其他构建更大的方法，例如CloudI 的 SOA 方法（参见 cmets）。如果您真的真的需要，您也可以构建使用hidden nodes 的集群。
在节点级别，您将采用不同的方法，例如，构建相同的节点，如果它们发生故障并且工作由其余节点接管，则它们很容易替换。查看 Riak 如何处理此问题（查看 riak_core 并查看博客文章 Introducing Riak Core）。
节点可以离开和进入一个集群，但不能同时成为多个集群的一部分。连接的节点共享一个用于识别连接节点的集群 cookie。您可以在 VM 运行时设置 cookie（请参阅Distributed Erlang）。
阅读http://learnyousomeerlang.com/ 以获得更大的好处。
【解决方案2】：
分发协议旨在提供稳健性，而不是可扩展性。您要做的是将集群分组为更小的区域，然后使用连接，这些连接不是在 Erlang 中分布，而是在 TCP 会话中。您可以运行 5 组，每组 10 台机器。这意味着这 10 台机器具有无缝的 PID 分配：您可以在另一台机器上调用一个 pid。但是分发到另一个组意味着你不能像那样无缝地解决这个组。
您通常需要 BGP 中的某种“路由反射”。
【解决方案3】：
1）我认为您需要节点之间的直接连接才能在进程之间进行通信。但是，这确实意味着，如果两个节点永远不会通信（例如，如果他们只是工作人员，而不是协调员），则您不需要所有节点之间的持久连接。
2) 您可以创建一个不完全连接的 erlang 节点图。该文档很难找到，并且存在问题 - 您禁用了处理集群中全局名称的global 系统，因此您必须通过本地注册的名称或远程节点上的本地注册名称来完成所有操作。或者只是使用 Pids，因为它们也可以工作。要像这样启动 erlang 节点，请使用 erl ... -connect_all false ...。我希望您知道自己在做什么，因为我无法相信自己会这样做。
事实证明，不完全连接的 erlang 节点图是当前的研究课题。 RELEASE Project 目前正致力于此，并提出了 S-groups 的概念，它本质上是完全连接的组。但是，节点可以是多个 S-group 的成员，并且不同 s-group 中的节点不必完全连接，但可以根据需要建立连接以进行直接的节点到节点通信。值得查找他们的演示文稿，因为这项研究非常有趣。
另一件值得指出的事情是，有几个人发现你可以在一个全连接的集群中获得多达 150-200 个节点。你真的有比这更多节点的用例吗？肯定有 150 到 200 台非常强大的计算机可以完成大部分你可以扔给它们的事情，除非你有一个荒谬的项目要做。
3) 虽然您不能使用gen_server:start_link/3,4 在不同的节点上启动进程，但您当然可以非常轻松地调用外部节点上的服务器。似乎他们忽略了在外部节点上启动服务器的能力，但这可能是有充分理由的——比如错误案例数量多得离谱。
4) 尝试查看隐藏节点以及未完全连接的集群。它们应该允许您根据需要对节点进行分组。
TL;DR：扩展很难，我们去购物吧。
【解决方案4】：
已经有一些很好的答案，所以我尽量简单。
1) 不，如果A 和E 没有直接连接，A 不能与E 对话。分发协议在直接 TCP 连接上运行 - 不包括路由。
2) 我认为树形结构就足够了——权衡总是存在的。
3) 没有“节点主管”，但 erlang:monitor_node 是你的朋友。
4) 是的。一个节点可以与来自不同“集群”的节点通信。在本地节点中，使用erlang:set_cookie(OtherNode, OtherCookie) 访问具有不同cookie 的远程节点。
【解决方案5】：
1)
是的。他们互相交谈
2) 3) 和 4)
一般来说，在构建一个可扩展和容错的系统时，您会希望，或者更多，需要将工作负载划分到不同的“区域”或“集群”。 Supervisor/Worker 模型具有这样的构想，因此拓扑结构。您需要的是几个进程协调集群之间的工作，并且单个集群中的所有工作人员将相互交谈以在组内平衡。
如您所见，使用这种拓扑结构，只要您以平衡的方式仔细分配任务，“限制”就不是真正的限制。就个人而言，我相信在大型系统中，主管流程的树状结构是不可避免的，这就是我正在遵循的做法。原因各不相同，但归结为可扩展性、作为回退策略实施的容错性、维护需求和集群的可移植性。
总之，
2) 为您的主管使用树状拓扑。让工作人员明确地相互联系并在自己的域内与主管交谈。
3) 虽然这是本机设计的环境，但我认为，我很确定主管可以与另一台机器上的工作人员交谈。我不建议这样做，因为在远程工作者场景中容错可能是地狱。
4) 你不应该让一个节点同时成为两个不同集群的一部分。不过，您可以将其从一个集群切换到另一个集群。