我们计划从与每个客户端部署相关的一系列静态配置文件中迁移出来。
所有客户端数据都存在于MySQL中,客户端部署的元数据存在于静态文本文件中:要使用的数据库/分片,文件存储的存储库目录/位置以及更多信息(如默认值)分页,费率和启用的模块。
我们希望摆脱这些静态配置文件 - 这些文件目前不仅仅是键值对,而是利用Perl的哈希和数组,但可以通过一些努力进行简化,并使用某些东西它可以存在于快速响应的数据库,LDAP或其他存储库中。 LDAP的灵活结构 - 允许嵌套/层次化数据我认为 - 看起来很吸引人,但我想知道是否有其他建议关于最好的方法这样做我不认为LDAP真的是为此而设计的,它已经存在了很长一段时间。
我们用来识别部署,数据库,存储库路径和其他变量的“密钥”将是部署的“域”(这些将是唯一的),理想情况下我们希望配置存储解决方案是多个服务器可以非常快速地(通过LAN)查询的中心点或联合服务。
对这些数据进行的“更新”操作很少,但读取率非常频繁,因此读取速度至关重要。
有什么建议吗?
杰夫
答案 0 :(得分:1)
我的解决方案是将配置放在与应用程序相同的数据库中。这样,我可以简单地将一个DB连接器传递给应用程序,它将使用正确的配置。
在应用程序中,配置是通过全局配置实例访问的,该实例将一次性读取数据库中的所有值并缓存它们。对于基于Web的应用程序,我使用一个特殊的URL来告诉配置实例刷新自己。
对于其他应用,我使用本地文件。当文件存在时,重新读取配置数据。您可以在第二个线程中执行此操作,或者每次只检查文件。由于路径是静态的,因此操作系统可以优化此访问,直到花费很少的时间。读取配置后,文件被删除,所以我知道重新加载了。
答案 1 :(得分:0)
免责声明:我正在开发一种工具来协助部署(但我并不主张它的用法)
我建议您只拥有一个分发配置的私人网站,并将其缓存在您的“阅读”应用中。然后,当发生更新时,您可以让中央服务器“ping”外部,建议他们刷新缓存(或者在客户端缓存到期时将其发生)。
答案 2 :(得分:0)
这可能是各种各样的“不答复”,但请考虑以下因素:您是否试图以一种在未来引入更多问题的方式解决感知问题?您已经提到过您对依赖于配置文件内部的Perl数据结构的依赖。考虑一下所有这些配置数据都存在于RDBMS中。在一个提供非常不同功能的系统中,您将如何使用现有方法“免费”复制您获得的功能?难道你不会在某些时候最终得到包含你旧的Perl数据结构的CLOB列吗?
究竟是什么驱使您远离当前的配置机制?我觉得这些问题可以自己解决,而不需要大规模的建筑剧变。