我已经尝试在StackOverflow上找到一些东西，但是所有已回答的问题都不能对我的用例有所帮助。这不只是关于使用或不使用哪种方法的信息，而是更多地关注于实现细节。我做的事正确与否：o
我正在尝试实现多个节点之间的配置共享，但不仅仅是在节点之间共享相同的配置，这实际上是在节点之间分配此conf。 假设配置如下：
topicA 话题B 主题C topicD
我运行了3个节点，这看起来像这样： nodeA-topicA，topicB 节点B-topicC nodeC-topicD
所有节点在启动时都有一个包含所有主题的静态配置文件，然后我使用Zookeeper使它们知道可用的其他节点的数量，然后运行一种算法，将这些主题分配给所有节点。可用节点。 该算法对于所有节点都是相同的，并且是完全确定性的（每个节点的结果都相同）。
要更清楚一点： nodeA，nodeB和nodeC具有以下所有静态配置：
topicA 话题B 主题C topicD
然后，他们通过Zookeeper彼此见面，他们现在拥有以下节点信息： 节点A 节点B nodeC
他们运行算法，然后将nodeA与topicA和topicB关联起来，这就是nodeA知道应仅处理topicA和topicB的方式
我本可以使用领导人选举的食谱，但是，imo，这会使事情变得更加复杂。
进入细节，比较棘手。 这个想法是，当节点收到ZK事件（节点已删除/添加）时，在进行重新平衡之前，应首先停止其作业并等待所有可用节点也停止其作业。我不能在同一主题上使用两个节点，这是强制性的。
因此，我添加了另一个ZK机制，如下所示： 当节点接收到一个事件（添加/删除节点）时，它停止其作业，然后在完成其作业时以ZK中的当前时间戳更新停止标记。 同样，无论何时删除或添加节点，所有节点都将更新ZK共享时间标记（称为lastupdatedmarker）。它们都共享相同的时间标记。 然后，节点等待所有可用的节点停止标记位于lastupdatemarker之上，这意味着它们都停止了工作并准备重新平衡配置。
然后，与此有关的一个问题是，如果在一个节点更新了停止标记之后但在收敛之前，我添加或删除了一个节点，那么我可能会错过更改，从而导致永远等待节点。为此，我添加了ShouldRebalance标志，该标志在这段时间内发生ZK Node事件（添加/删除）时设置为true。
它似乎正常工作。.但是我很确定这种设计存在缺陷，并开始认为我做的事情可能不正确。 我阅读了策展人的不同食谱，它们的确确实更可靠，但不确定它们是否可以100％正确地处理此用例。
有什么建议吗？
此致
Yann