我们正在设计一个客户端/服务器程序，我需要一些关于设计决策的帮助。
该程序的服务器端将作为服务在多个 Windows 服务器上运行，该服务正在监视这些服务器，需要时该服务将通过电子邮件向我们发送报告。
客户端将用于控制和管理服务器上运行的服务，但不会一直运行。
我的问题是我应该在哪里以及如何存储服务的配置。设置（smtp 等）将在客户端上定义，但在远程服务器上运行的服务（可能有很多）需要使用设置进行更新，并保留这些设置直到它们再次更新。
我可以想到两个选项，一个中央 Windows 共享，服务从中读取设置，或者当客户端点击“保存”时，设置将保存到每台服务器上的某个位置。
你会怎么办？有什么我应该注意的吗？
谢谢
我没有使用此类服务的经验，但建议可能是将设置存储在他们都可以访问的中央数据库中。因此，每次创建新服务器时，都会在数据库中创建一个新的设置条目。
只是把这个放到讨论中。
我开发了一个涉及客户端和多个服务器的系统。我的系统的要求包括它非常可靠和高度可用（这可能不是您的要求）。从这个角度来看，这里有一些想法：
如果您将设置存储在中央位置（文件共享或数据库），则您在分布式系统中创建了单点故障。一种解决方法是将设置存储在 2 个或更多中心位置。但是，您如何确保 2 个或更多位置同步？）
如果您将设置存储在每台服务器上，如果在您尝试保存设置时客户端/服务器与一台服务器的通信失败怎么办，或者如果其中一台服务器未启动怎么办。现在您遇到了服务器不同意设置的情况。那么，再一次，您如何确保多个服务器同步？
所以....想一想如何可靠地保持服务器同步，以及它们如何检测它们何时不同步。在我的系统中，服务器之间有一个主/从方案，带有序列号的心跳，以便从属可以不断地确保它们是同步的并且没有错过任何消息。如果 master 宕机了，系统会降级，但仍然可以工作，因此 master 不是灾难性的单点故障。
这里有很多事情需要考虑。
显而易见的选择是存储库，无论是服务器端的注册表、文件还是数据库。当您的服务加载时，您会在一个集合中获取所有这些设置。但是，当您在服务器端添加一项服务以监控其他一些任务时会发生什么。
现在您遇到了问题，因为如果通过一台服务器在数据库中更新了参数，则需要将更新通知其他服务并且它们需要重新初始化。
您可以通过在许多服务之间引入许多 IPC 机制来克服这个问题，即队列、共享内存、管道、套接字。如果服务不是分布式的，我建议共享内存；如果不是，我建议在中央服务器或数据库上使用队列；作为更好的选择。然而，服务仍然需要协作一些如何向其他服务提供有关参数更新的提示。