如何才能拥有超快的动态配置？
我们计划迁移与每个客户端部署相关的一系列静态配置文件。
所有客户端数据都位于 MySQL 中，客户端部署的元数据位于静态文本文件中：使用什么数据库/分片、文件存储的存储库目录/位置以及更多信息，例如默认分页、费率并启用模块。
我们希望摆脱这些静态配置文件（目前它们不仅仅是键值对，并利用 Perl 的散列和数组，但可以通过一些努力来简化）并利用可以生存的东西在快速响应的数据库、LDAP 或其他存储库中。 LDAP 的灵活结构（我认为它允许数据嵌套/层次结构）看起来很吸引人，但我想知道是否还有其他关于实现此目的的最佳方法的建议，我认为 LDAP 并不是真正为此设计的，而且它已经存在很长一段时间了。
我们用来识别部署、数据库、存储库路径和其他变量的“键”将是部署的“域”（这些将是唯一的），理想情况下，我们希望配置存储解决方案成为中心点或联合服务，多个服务器可以非常快速地查询（通过 LAN）。
对此数据进行的“更新”操作很少，但读取率将非常非常频繁，因此读取速度至关重要。
有什么建议吗？
杰夫
We're planning to migrate away from a series of static config files related to each client deployment.
All client data lives in MySQL, the meta-data for a client deployment lives in a static text file: what database/shard to use, the repository directory/location for the file store, and a bunch more info such as default pagination, rates and enabled modules.
We want to move away from these static config files—which are more than just key-value pairs at the moment and make use of Perl's hashes and arrays, but could be simplified that way with some effort—and make use of something which can live in a fast-responding database, LDAP or other repository. The flexible structures of LDAP—which allow nesting/hierarchy of data I think—look appealing, but I was wondering whether there was some other advice about the best way to do this I don't think LDAP was really designed for this, and it has been around for a long while.
The "key" we would use to identify a deployment, database, repository path and other variables will be the "domain" of the deployment (these will be unique), and ideally we'd like the config storage solution to be a central point or federated service that multiple servers can query very quickly (over a LAN).
Very few "update" actions will be undertaken on this data, yet the read rates will be very very very frequent, so speed of read is critical.
Any advice?
Geoff
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的解决方案是将配置放在与应用程序相同的数据库中。这样，我可以简单地将一个数据库连接器传递给应用程序，它就会使用正确的配置。
在应用程序中，配置是通过全局配置实例访问的，该实例会一次性从数据库中读取所有值并缓存它们。对于基于 Web 的应用程序，我使用特殊的 URL 来告诉配置实例自行刷新。
对于其他应用程序，我使用本地文件。当文件存在时，将重新读取配置数据。您可以在第二个线程中执行此操作，或者每次都检查文件。由于路径是静态的，操作系统可以优化此访问，直到花费很少的时间。读取配置后，文件被删除，所以我知道发生了重新加载。
My solution was to put the config in the same database as the application. That way, I could simply pass one DB connector to the app and it would use the correct config.
In the app, the config was accessed via a global config instance which would read all values from the database in one go and cache them. For a web based app, I use a special URL to tell the config instance to refresh itself.
For other apps, I use a local file. When the file exists, the config data is reread. You can do this in a second thread or just check for the file every time. Since the path is static, the OS can optimize this access until it take very little time. After the config has been read, the file is deleted, so I know that the reload happened.
免责声明：我正在开发一个辅助部署的工具（但我并不提倡您使用它）
我建议您拥有一个分发配置的私人网站，并将它们缓存在您的“阅读”中'应用程序。然后，当发生更新时，中央服务器可能能够“ping”外部服务器，建议它们刷新缓存（或者作为客户端上缓存到期的一部分而发生这种情况）。
disclaimer: I work on a tool to assist deployment (but I'm not advocating it's usage for you)
I suggest you just have a private website that distributes the configs, and simply cache them in your 'reading' apps. Then you may have the ability for the central server to 'ping' the externals, when an update occurs, suggesting that they refresh their cache (or have that happen as part of a cache expiry on the clients).
这可能是某种“非答案”，但请考虑以下问题：您是否试图以一种会在未来引入更多问题的方式解决感知到的问题？您已经提到您对配置文件中的 Perl 数据结构的依赖。考虑一下所有这些配置数据都位于 RDBMS 中。您将如何在提供一组非常不同的功能的系统中复制使用现有方法“免费”获得的功能？您是否会在某个时刻最终得到包含良好的旧 Perl 数据结构的 CLOB 列？
到底是什么让您放弃当前的配置机制？我有一种感觉，这些问题可以自行解决，而不需要大规模的架构剧变。
This may be a "non answer" of sorts, but consider the following: are you trying to solve a perceived problem in a way that would introduce even more issues in the future? You've mentioned your reliance on Perl data structures that live inside config files. Consider for a moment that all this configuration data lives in a RDBMS. How would you go about replicating the functionality that you get "for free" with your existing approach, in a system that provides a very different set of functionality? Wouldn't you at some point end up with CLOB columns containing your good old Perl data structures?
What exactly is driving you away from your current configuration mechanism? I have a feeling that those issues could be addressed on their own without necessitating a large-scale architectural upheaval.