Configuration 如何设计一个能够以动态方式高效管理配置的系统？

我正在设计一个系统，在这个系统中，我需要跨多个应用服务器动态管理配置（配置文件）。我正在与Concur key value store合作管理配置

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

为了管理配置，我在Concur kv store中创建了以下节点

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

这里

remoteConfig

包含所有应用服务器将使用的配置文件（至少这是我得到的设计）

以下是我正在尝试做的事情：

• 所有的应用程序服务器都会监视Consor中的上述节点，只要

  remoteConfig

  键的值发生变化，就会通知他们，然后他们会下载此配置并将其存储在磁盘上
• 现在，一旦集群中的所有应用服务器都下载了新配置，那么仅我们应该切换到在集群中的所有框中使用内存中的新配置。如果少数应用程序服务器未能下载，那么我们不应该在成功下载的剩余框中切换到使用最新配置

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

问题：

• 我应该如何以这样的方式设计我的节点，使我更容易看到所有的机器都成功地下载了这个特定的配置？现在是时候切换到所有机箱上的最新配置了
• 如果某些机器未能下载特定配置，那么从阅读中应该可以清楚地看到，此应用程序服务器未能下载，并且可能还会显示时间戳，就像此应用程序服务器在此时间戳下载了此配置，并且在该时间戳切换到新配置一样

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

---

（注意：我也可以有一堆其他节点（比如状态节点）来做这个练习，仅供参考。我们也可以使用Zookeeper来代替Concur，这两种技术都可以使用bcoz锁定/引导功能，但现在我要坚持Concur）

我无法回答您的问题，但我担心的是，如果你想办法实现既定目标，可能会出现潜在的种族状况

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

如果这种短暂的不一致性会给您带来问题，那么我认为您将需要一种不同的“从配置的版本1切换到版本2”机制，其本质可以归结为：（1）要求所有服务器进程终止；（2） 等待它们全部终止，（3）使用配置的版本2重新启动它们。显然，这种方法需要一段短时间的服务器不运行，这并不理想，但至少可以避免竞争情况