配置文件与数据库表
我特别感兴趣的场景是多个服务器具有在某些配置参数上运行的守护程序。 （因为，这是一个学习练习。我欢迎除此特定案例之外的任何想法） 问题是，配置参数应该放在哪里。
A. 中央数据库表
B. 推送到每个框的配置文件
这些是我遇到的最常见的情况。其他值得注意的是，在代码常量中（需要重新编译才能部署。除非它们确实是常量，否则这是一个糟糕的选择），配置文件安装在共享位置。
只是想从社区中了解您如何做出选择。
The scenario I am particularly interested is multiple servers having daemons that run on certain configuration parameters. (since, this is a learning exercise. i welcome any thought beyond this particular case)
The question is, where should the configuration parameters sit.
A. a central database table
B. a config file pushed to each of the boxes
These are the most common I've come across. The notable others being, in code constants (needs recompile to deploy. so bad option unless they really are constants), config file mounted on a shared location.
Just wanted to know from the community on how you go about making the choice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这完全取决于您所管理的运营规模。
如果位置数量很大和/或更改很频繁，请使用数据库。
否则，请使用配置文件。
如果访问集中式数据库的速度太慢或出现无法接受的故障点，但规模仍然很大，请使用像 Puppet 这样的自动化系统。
It all depends on the scale of the operation you're managing.
If the number of locations is large and/or changes are frequent, use a database.
Otherwise, use configuration files.
If access to a centralized database is too slow or unacceptably a point of failure, but the scale is still large, use an automated system like Puppet.
如果配置属性可以在运行时更新，那么将属性集中在数据库中将使生活变得更轻松。
If the config properties can be updated at runtime, centralizing the properties in the DB will make life easier.
大多数需要在服务器/应用程序之间共享配置参数的公司最终都会创建自己的配置机制并将其存储在本地关系数据库中。我认为规模根本不重要。必须登录多个服务器才能检查文件系统上的配置是一场噩梦。然而，即使在中央数据库中管理配置，您仍然必须确保配置易于访问。我已经在 3 个不同的公司看到过这种类型的配置，唯一真正成功使用的地方是应用程序公开了一个简单的用户界面，允许系统管理员调整设置。如果只能使用 SQL 客户端访问它，您会发现配置很容易“丢失”，或更糟糕的是，配置会被重复。
上面的海报提到了 Puppet，我从未使用过它，但它看起来很有趣。然而，它看起来还不支持 Windows [1]：http://www.puppetlabs。 com/puppet/requirements/
Most companies with a need to share configuration parameters between servers/applications end up creating their own configuration mechanisms and storing them in a home-rolled relational database. I would argue that the scale doesn't even matter. Having to log into multiple servers in order to check a configuration on the file system is a nightmare. However, even when managing configuration in a central database, you still have to make sure that the configuration is easy to access. I've seen this type of configuration used at 3 different companies, and the only place that it was used in a truly successful manner, was where the application exposed a simple user interface allowing system administrators to tweak the settings. If it's only accessible by using a SQL client, you'll find that configurations will easily get "lost" or worse, duplicated.
The above poster mentioned Puppet, which I've never used, but it looks VERY interesting. However it doesn't look like it supports Windows yet [1]: http://www.puppetlabs.com/puppet/requirements/