种子节点配置的差异如何影响集群的形成？
How does discrepancy of seed-nodes configuration affect cluster formation?
假设节点 A、B、C 和 D 由以下配置聚类，
cluster {
seed-nodes = ["A", "B", "C", "D"]
}
和节点 C 和 D 添加节点 E, F和G即将在以下配置下部署：
cluster {
seed-nodes = ["C", "D", "E", "F", "G"]
}
在这种情况下，部署的顺序会影响集群的形成吗？换句话说，下面的两种情况是否会产生相同的集群：
- 部署E、F和G，然后重新部署C和D，或
- 重新部署C和D，然后部署E，F 和 G.
根据the Akka documentation，seed-nodes中的第一个节点在集群形成中起着特殊的作用：
but the node configured as the first element in the seed-nodes list must be started when initially starting a cluster. If it is not, the other seed-nodes will not become initialized, and no other node can join the cluster.
因为在后一种情况下节点 C 开始时没有节点 D, E, F和G属于一个集群，应该新建一个集群。但是，在前一种情况下，在重新部署 C 和 D 之前，节点 E、F和G通过C和D[=61=加入现有集群]，重新部署 C 和 D 不会改变任何东西，因为有些节点已经属于集群。我说得对吗？
也许吧，这取决于你如何“重新部署”。但是让我详细介绍一下，因为我必须多次阅读您的问题才能（我认为）理解您的要求。然后我会提出一些一般性的建议。
基本上你有两种配置：一种以 [A,B,C,D] 作为种子节点，另一种以 [C,D,E,F,G] 作为种子节点。我将它们称为配置 1 和配置 2。然后您将有两种场景，在这些场景中您以不同的顺序启动和停止并重新配置节点。但我不太确定你的步骤之一，所以我实际上定义了场景 1、场景 2a 和场景 2b。:
- 场景一：按照A-1、B-2、C-1、D-1的顺序启动节点。 （意思是用配置 1 启动那些节点。）等待集群形成。部署 E-2、F-2、G-2。停止 C-1、D-1、重新配置、部署 C-2，然后部署 D-2。
- 场景2a：按照A-1、B-2、C-1、D-1的顺序启动节点。等待集群形成。停止 C-1，重新配置 C，然后部署 C-2，然后顶部 D-1，重新配置 D，部署 D-2，然后 E-2，F-2，G-2。
- 场景2b：按照A-1、B-2、C-1、D-1的顺序启动节点。等待集群形成。停止 C-1，停止 D-1。重新配置 C+D，然后部署 C-2，部署 D-2，然后部署 E-2、F-2、G-2。 （与 2a 的区别在于您同时停止了 C 和 D。）
正如您所指出的，种子中的第一个节点具有启动新集群的独特能力。因此，如果我们遍历场景 1：
- A-1 开始。他试图从 B、C 或 D 中发现一个 运行 星团。他在这些地方都找不到 运行 星团，因此他将使用他的特殊能力开始一个新的星团。
- B-1然后开始，并尝试从A、C或D找到一个集群。他在A找到一个并加入它。
- 然后C-1开始，并尝试从A、B或D中找到一个簇。他可能在A或B中找到它，这无关紧要。
- 然后D-1启动，按照同样的流程找到集群并加入集群。
- 你并没有真正指定它们是按这个顺序启动的，但这并不重要。由于它们具有相同的配置，因此它们最终都会形成一个由四个节点组成的集群。
- E-2 随后部署。尽管他有不同的配置，但这并不重要：他将从 C、D、F、G 中寻找集群。他会在 C 或 D 找到它并加入。
- F 和 G 相同。
- 然后你说“重新部署 C 和 D”，我会将其解释为停止、更改配置并重新启动。假设 E、F 和 G 成功上线，C 和 D 将通过这三台服务器中的一台找到集群并加入。通过加入集群，他们将了解 A 和 B；种子节点仅用于集群发现。一旦加入，他们就会从共识中获得完整的节点列表。
- 所以我们最终得到一个包含所有节点的集群：A、B、C、D、E、F、G。
场景 2a：
- 创建 A、B、C、D 的初始集群的初始过程相同。
- 但随后C和D被“重新部署”。如果您一次停止、重新配置并重新启动它们，那么 C 将通过 D 找到现有集群。然后 D 将通过重新启动的 C 找到集群。
- 然后当您启动 E、F 和 G 时，它们会通过其他任何一个找到集群，您最终会得到一个包含所有节点的集群：A、B、C、D、E、F、G .
场景 2b：
- 创建 A、B、C、D 的初始集群的初始过程相同。
- 但随后C和D被“重新部署”。这次我们假设您将它们都关闭了。重新配置它们。然后重新部署它们。
- 在这种情况下，当 C 重新启动时，他的配置中没有提及 A 或 B，因此他无法找到它们（因此无法找到原始集群）。所以他，既然他现在被列为初始种子节点，就会用他独特的能力来启动一个新的集群。
- D 将加入新集群（因为他同样无法找到原始集群）。然后与 E、F、G 等相同，因为他们将很容易找到第二个集群。 （但将无法找到初始簇。）
- 您最终会得到两个集群：一个包含 A、B，第二个包含 C、D、E、F、G。
对此的几点评论：
- 这说明了为什么种子节点并不是真正的首选策略。
- 它说明了为什么种子节点列表中的第一个条目很重要：创建新集群的能力受到专门限制，以防止出现像这样的孤立集群。当你改变它时，你需要确保这个新的“特殊节点”启动时它不会启动一个新的集群。 （除非那正是您的目标。）
- 您的示例将所有节点列为种子节点。这有点不寻常。您没有列出所有节点；您只是给新节点一个“起点”，以便它们可以找到现有的集群。并且可以争论说，无论您的集群有多大，您实际上应该只拥有 2-3 个种子节点。部分原因是您不想在任何时候想要添加成员时都必须更改该列表。 （因为你最终会遇到这样的场景。）
- 这也有点表明集群的意图是非常长 运行。我实际上知道一个案例，他们在集群形成后故意停止初始种子节点，从而无法创建新的集群。 （只有在他们想要重启集群的极少数情况下才手动重启该节点。）
假设节点 A、B、C 和 D 由以下配置聚类，
cluster {
seed-nodes = ["A", "B", "C", "D"]
}
和节点 C 和 D 添加节点 E, F和G即将在以下配置下部署：
cluster {
seed-nodes = ["C", "D", "E", "F", "G"]
}
在这种情况下，部署的顺序会影响集群的形成吗？换句话说，下面的两种情况是否会产生相同的集群：
- 部署E、F和G，然后重新部署C和D，或
- 重新部署C和D，然后部署E，F 和 G.
根据the Akka documentation，seed-nodes中的第一个节点在集群形成中起着特殊的作用：
but the node configured as the first element in the seed-nodes list must be started when initially starting a cluster. If it is not, the other seed-nodes will not become initialized, and no other node can join the cluster.
因为在后一种情况下节点 C 开始时没有节点 D, E, F和G属于一个集群，应该新建一个集群。但是，在前一种情况下，在重新部署 C 和 D 之前，节点 E、F和G通过C和D[=61=加入现有集群]，重新部署 C 和 D 不会改变任何东西，因为有些节点已经属于集群。我说得对吗？
也许吧，这取决于你如何“重新部署”。但是让我详细介绍一下，因为我必须多次阅读您的问题才能（我认为）理解您的要求。然后我会提出一些一般性的建议。
基本上你有两种配置：一种以 [A,B,C,D] 作为种子节点，另一种以 [C,D,E,F,G] 作为种子节点。我将它们称为配置 1 和配置 2。然后您将有两种场景，在这些场景中您以不同的顺序启动和停止并重新配置节点。但我不太确定你的步骤之一，所以我实际上定义了场景 1、场景 2a 和场景 2b。:
- 场景一：按照A-1、B-2、C-1、D-1的顺序启动节点。 （意思是用配置 1 启动那些节点。）等待集群形成。部署 E-2、F-2、G-2。停止 C-1、D-1、重新配置、部署 C-2，然后部署 D-2。
- 场景2a：按照A-1、B-2、C-1、D-1的顺序启动节点。等待集群形成。停止 C-1，重新配置 C，然后部署 C-2，然后顶部 D-1，重新配置 D，部署 D-2，然后 E-2，F-2，G-2。
- 场景2b：按照A-1、B-2、C-1、D-1的顺序启动节点。等待集群形成。停止 C-1，停止 D-1。重新配置 C+D，然后部署 C-2，部署 D-2，然后部署 E-2、F-2、G-2。 （与 2a 的区别在于您同时停止了 C 和 D。）
正如您所指出的，种子中的第一个节点具有启动新集群的独特能力。因此，如果我们遍历场景 1：
- A-1 开始。他试图从 B、C 或 D 中发现一个 运行 星团。他在这些地方都找不到 运行 星团，因此他将使用他的特殊能力开始一个新的星团。
- B-1然后开始，并尝试从A、C或D找到一个集群。他在A找到一个并加入它。
- 然后C-1开始，并尝试从A、B或D中找到一个簇。他可能在A或B中找到它，这无关紧要。
- 然后D-1启动，按照同样的流程找到集群并加入集群。
- 你并没有真正指定它们是按这个顺序启动的，但这并不重要。由于它们具有相同的配置，因此它们最终都会形成一个由四个节点组成的集群。
- E-2 随后部署。尽管他有不同的配置，但这并不重要：他将从 C、D、F、G 中寻找集群。他会在 C 或 D 找到它并加入。
- F 和 G 相同。
- 然后你说“重新部署 C 和 D”，我会将其解释为停止、更改配置并重新启动。假设 E、F 和 G 成功上线，C 和 D 将通过这三台服务器中的一台找到集群并加入。通过加入集群，他们将了解 A 和 B；种子节点仅用于集群发现。一旦加入，他们就会从共识中获得完整的节点列表。
- 所以我们最终得到一个包含所有节点的集群：A、B、C、D、E、F、G。
场景 2a：
- 创建 A、B、C、D 的初始集群的初始过程相同。
- 但随后C和D被“重新部署”。如果您一次停止、重新配置并重新启动它们，那么 C 将通过 D 找到现有集群。然后 D 将通过重新启动的 C 找到集群。
- 然后当您启动 E、F 和 G 时，它们会通过其他任何一个找到集群，您最终会得到一个包含所有节点的集群：A、B、C、D、E、F、G .
场景 2b：
- 创建 A、B、C、D 的初始集群的初始过程相同。
- 但随后C和D被“重新部署”。这次我们假设您将它们都关闭了。重新配置它们。然后重新部署它们。
- 在这种情况下，当 C 重新启动时，他的配置中没有提及 A 或 B，因此他无法找到它们（因此无法找到原始集群）。所以他，既然他现在被列为初始种子节点，就会用他独特的能力来启动一个新的集群。
- D 将加入新集群（因为他同样无法找到原始集群）。然后与 E、F、G 等相同，因为他们将很容易找到第二个集群。 （但将无法找到初始簇。）
- 您最终会得到两个集群：一个包含 A、B，第二个包含 C、D、E、F、G。
对此的几点评论：
- 这说明了为什么种子节点并不是真正的首选策略。
- 它说明了为什么种子节点列表中的第一个条目很重要：创建新集群的能力受到专门限制，以防止出现像这样的孤立集群。当你改变它时，你需要确保这个新的“特殊节点”启动时它不会启动一个新的集群。 （除非那正是您的目标。）
- 您的示例将所有节点列为种子节点。这有点不寻常。您没有列出所有节点；您只是给新节点一个“起点”，以便它们可以找到现有的集群。并且可以争论说，无论您的集群有多大，您实际上应该只拥有 2-3 个种子节点。部分原因是您不想在任何时候想要添加成员时都必须更改该列表。 （因为你最终会遇到这样的场景。）
- 这也有点表明集群的意图是非常长 运行。我实际上知道一个案例，他们在集群形成后故意停止初始种子节点，从而无法创建新的集群。 （只有在他们想要重启集群的极少数情况下才手动重启该节点。）