代码之家  ›  专栏  ›  技术社区  ›  Glen

其中\如何存储分布式配置数据

  •  1
  • Glen  · 技术社区  · 15 年前

    我们产品的单个安装将其配置存储在一组数据库表中。

    没有任何安装“知道”任何其他安装。

    对于客户来说,在地理上相距很远的不同数据中心安装我们产品的多个副本是很常见的。这意味着配置信息需要创建一次,然后导出到其他系统。然后修改一些配置以适应本地条件。例如,更改IP地址等。这是一种笨拙、容易出错的方法。

    我们现在正收到请求,要求能够有一个更无缝的策略来共享全球数据,但仍然允许本地修改。

    如果不是本地修改位,那么我们可以使用Oracle的数据复制功能。

    由于HA的要求,一个数据库中的所有配置都不是一个选项。

    有没有其他人遇到过这个问题,你有没有想出一个很好的方案来解决这个问题?知道有什么好论文可以描述部分或全部的解决方案吗?

    我们基于*nix,使用Oracle。应该很快地将更改复制到所有节点(一秒钟或2秒钟)。

    2 回复  |  直到 11 年前
        1
  •  2
  •   Steve Broberg    15 年前

    我不确定您如何改变处理配置的方式,但是我们通过使用本地重写的思想实现了类似的功能。具体来说,您有两个相同的配置表(称为centralconfig和localconfig)。centralconfig保存在中心位置,并复制到卫星位置,在那里它是只读的。可以在本地站点上设置localconfig。查询配置数据的过程首先在localconfig表中查找数据,如果找不到,则从centralconfig表中检索数据。

    例如,如果您试图使用v$参数表中的值执行此操作,则可以使用SQL分析中的第一个“值”函数查询配置:

      SELECT DISTINCT
             NAME
           , FIRST_VALUE(VALUE) OVER(PARTITION BY NAME 
                                         ORDER BY localsort
                                    ) VALUE
        FROM (SELECT t.*
                   , 0 localsort
                FROM local_parameter t
               UNION
              SELECT t.*
                   , 1 localsort
                FROM v$parameter t
             )
    ORDER BY NAME;
    

    联合中的localsort列只是为了确保本地_参数值优先于v$参数值。

    在我们的系统中,它实际上比这个复杂得多。除了要查找的参数的“名称”之外,我们还有一个“上下文”列,描述我们要查找的上下文。例如,我们可能有一个中央设置的参数“timeout”,但即使在本地,我们也有多个使用该值的组件。它们可能都是相同的,但我们也可能希望对它们进行不同的配置。因此,当工具查找“超时”值时,它还受范围的约束。在配置本身中,我们可以在定义范围所需的内容时使用通配符,例如:

    CONTEXT       NAME    VALUE
    ------------- ------- -----
    Comp Engine A timeout    15
    Comp Engine B timeout    10
    Comp Engine % timeout     5
    %             timeout    30
    

    上面的配置说明,对于所有组件,使用30的超时,但是对于任何类型的comp引擎,使用5的超时,但是对于comp引擎A&B,分别使用15&10。最后两个配置可以在centralconfig中维护,但另外两个配置可以在localconfig中维护,您可以通过以下方式解析设置:

      SELECT DISTINCT
             NAME
           , FIRST_VALUE(VALUE) OVER(PARTITION BY NAME 
                                         ORDER BY (TRANSLATE(Context
                                                            , '%_'
                                                            , CHR(1) || CHR(2)
                                                  ) DESC
                                                , localsort
                                    ) VALUE
        FROM (SELECT t.*
                   , 0 localsort
                FROM LocalConfig t
               WHERE 'Comp Engine A' LIKE Context
               UNION
              SELECT t.*
                   , 1 localsort
                FROM CentralConfig t
               WHERE 'Comp Engine A' LIKE Context
             )
    ORDER BY NAME;
    

    它基本上是相同的查询,只是我在本地排序之前插入了转换表达式,并且限制了上下文。它所做的是将%和u字符转换为chr(1)&chr(2),这将使它们按字母数字字符降序排序。这样,明确定义的“comp engine a”将出现在“comp engine%”之前,而“comp engine%”又将出现在“%”之前。在上下文定义相同的情况下,本地配置优先于中心配置;如果您希望本地配置总是胜过中心配置,即使在中心配置范围更紧的情况下,您也只需反转这两个排序项的位置。

        2
  •  0
  •   ZangZhi    11 年前

    我们这样做的方式和史蒂夫的相似。 首先,您需要一个中心配置服务来保存所有要应用于分布式环境的配置。每次您想要修改配置时,都要在中央配置服务中对其进行修改。在每个生产主机中,您可以编写一个循环脚本来更新配置。 对于更复杂的解决方案,您需要设置一些策略,以避免在所有服务器中错误地配置批处理,这将是一个灾难。也许你需要一个简单的锁或者灰色释放过程。