【问题标题】:Sharing properties file from a single location从单个位置共享属性文件
【发布时间】:2010-05-17 15:30:22
【问题描述】:

我们将 Java Enterprise 应用程序部署到多台服务器上。有运行相同应用程序以进行负载平衡的复制服务器(我们称它们为 J2EE 服务器)。请注意,这不是集群的。

有一个公共服务器(我们称之为 props 服务器)托管与所有应用程序相关的所有属性文件。包含属性文件的文件夹是 NFS 在所有其他 J2EE 服务器之间共享的。 问题是您可以看到道具服务器是单点故障。如果它没有出现或者如果 NFS 共享被损坏,其他服务器将无法加载属性。

有哪些选项可以避免这种硬依赖? 鉴于我们不想将属性文件复制到所有服务器的约束。

【问题讨论】:

  • 为什么不想复制它们?我想运行一个辅助备份服务器只是为了托管属性是矫枉过正的:)
  • 这意味着一旦属性文件发生变化,它需要反映在所有相关的服务器上。

标签: java jakarta-ee properties nfs


【解决方案1】:

如果您遇到这个问题,更具扩展性的解决方案是考虑使用这个:

http://java.sun.com/j2se/1.4.2/docs/guide/lang/preferences.html

这会抽象出它们所在的位置。然后,您可以将这些设置存储在 LDAP 服务器、克隆属性或任何最好的东西中 - 您甚至可以为不同的环境使用不同的机制。

【解决方案2】:

其中一种方法是让每个 J2EE 服务器都拥有一组克隆的配置文件。这意味着每次更改一个服务器的配置时都应该在所有其他服务器中进行 rsync-ed 的约束(在已知更改正常之后)。

积极的一面很明显,您确实有 N 个独立可配置的服务器,而配置更改只会杀死(如果杀死)一台服务器。

不利的一面是,有时有人会在单个盒子上更改配置后忘记执行“rsync”和“bounce”。

【讨论】:

    【解决方案3】:

    鉴于我们没有 想要将属性文件复制到 所有服务器。

    如果您可以将属性复制到某些服务器,请选举领导者并确保将任何修改传播到备份,那么 Paxos 就是您的朋友。如果leader失败,可以选举新的leader。我已经更新了维基百科页面。它包含有关算法描述的错误。

    【讨论】:

      【解决方案4】:

      看一下 PAXOS 算法。它旨在使多个服务器达成共识。

      http://en.wikipedia.org/wiki/Paxos_algorithm

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2013-10-02
        • 2019-01-27
        • 2011-01-12
        • 2018-10-03
        • 1970-01-01
        • 1970-01-01
        • 2011-06-18
        相关资源
        最近更新 更多