【问题标题】:How to design a system that can manage configurations in a dynamic way efficiently?如何设计一个能够以动态方式有效管理配置的系统?
【发布时间】:2020-07-24 05:23:12
【问题描述】:

我正在设计一个系统,我需要在其中以动态方式跨多个应用程序服务器管理配置(配置文件)。我正在使用 Consul 键值存储来管理配置。

为了管理配置,我在 consul kv store 中创建了下面的节点。

{"remoteConfig":"abc-123.tgz", "...."}

这里remoteConfig 包含所有应用服务器将使用的配置文件(至少这是我得到的设计)。

以下是我想要做的:

  • 所有应用服务器都在 Consul 中监视上述节点,一旦 remoteConfig 键的值发生变化,他们将收到通知,然后他们将下载此配置并将其存储在磁盘上。
  • 现在,一旦集群中的所有应用服务器都下载了新配置,那么我们应该切换到在集群中的所有机器上使用内存中的新配置。如果少数应用服务器下载失败,那么我们不应该在成功的剩余框中切换到使用最新配置。

我能够轻松完成第一点,但我对如何有效地设计第二点感到困惑,这可以帮助我仅在所有应用服务器都下载了该特定配置时才切换到最新配置。我确实知道如何通过在 Consul 中获取和释放锁来自动更新节点,但困惑在于如何有效地设计它以轻松处理这些情况。

问题:

  • 我应该如何设计我的节点,以便我更容易看到所有机器都成功下载了这个特定的配置?现在是时候在所有盒子上切换到最新配置了。
  • 如果某些机器未能下载特定配置,那么从阅读中应该可以清楚地知道该应用服务器下载失败,也许它还可以显示时间戳,例如该应用服务器在此时间戳下载此配置,然后切换到新配置在这个时间戳。

我不必保留每台机器的所有配置状态的历史记录,只需最新的就足够了。上述设计也欢迎任何其他改进,以便以动态方式管理配置。

(注意:我也可以有一堆其他节点(比如状态节点)来做这个练习,仅供参考。另外,我们可以使用 Zookeeper 来代替 Consul,也可以使用 bcoz lock/leader 的东西两种技术都可以完成,但现在我会坚持使用 Consul)

【问题讨论】:

    标签: configuration apache-zookeeper distributed-system consul system-design


    【解决方案1】:

    我无法回答您的问题,但我担心如果您找到实现既定目标的方法可能会发生潜在的竞争状况。

    假设您有 5 台服务器,并且都使用版本 1 的配置文件。然后要求服务器下载配置文件的版本 2。当所有 5 台服务器都完成此操作后,您(以某种方式)向所有 5 台服务器发送信号,告诉它们从配置文件的版本 1 切换到版本 2。这是可能发生竞争条件的地方。从配置文件的版本 1 切换到版本 2 的配置文件不能保证在 5 台服务器中的每台服务器中同时发生。因此,在很短的一段时间内(可能只有几毫秒),一些服务器仍将使用版本 1,而其他服务器将使用版本 2。在这短暂的时间内,您的服务器上的配置将不一致。

    如果这种短暂的不一致会给您带来问题,那么我认为您将需要一种不同的“从配置的版本 1 切换到版本 2”的机制,其本质上归结为:(1)要求所有服务器进程终止; (2) 等待它们全部终止,(3) 使用版本 2 的配置重新启动它们。显然,这种方法需要一个短暂的服务器不运行期间,这并不理想,但至少它避免了竞态条件。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2016-10-11
      • 2022-08-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-03-26
      • 2010-10-07
      • 1970-01-01
      相关资源
      最近更新 更多