分布式配置数据在哪里\如何存储

Question

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

所有安装都不“了解”任何其他安装。

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

我们现在收到要求能够制定更无缝的全球数据共享策略的请求，但仍允许本地修改。

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

由于 HA 要求，将所有配置都放在一个数据库中不是一种选择。

有其他人遇到过这个问题吗？您是否为此找到了一个好的编程解决方案？ 知道任何可能描述部分或完整解决方案的好论文吗？

我们基于 *nix，并使用 Oracle。 更改应该很快（一秒或两秒）复制到所有节点。

Answer 1

我不确定您有多大可能改变处理配置的方式，但我们通过使用本地覆盖的想法实现了类似的东西。 具体来说，您有两个相同的配置表（称为 CentralConfig 和 LocalConfig）。 CentralConfig 在中央位置维护，并复制到您的卫星位置，在该位置它是只读的。 LocalConfig可以在本地站点设置。 查询配置数据的过程首先在 LocalConfig 表中查找数据，如果未找到，则从 CentralConfig 表中检索数据。

例如，如果您尝试使用 v$parameter 表中的值执行此操作，则可以使用 SQL 分析中的 FIRST_VALUE 函数查询您的配置：

  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 列只是为了确保 local_parameter 值采用优先于 v$ 参数值。

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

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

上面的配置表示，对于所有组件，使用超时 30，但对于任何类型的 Comp Engine，使用超时 5，但是对于 Comp Engines 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;

它基本上是相同的查询，除了我在 localsort 和 I' 之前插入 TRANSLATE 表达式m 限制上下文。 它所做的是将 % 和 _ 字符转换为 chr(1) & chr(2)，这将使它们按降序排列在字母数字字符之后。 这样，显式定义的“Comp Engine A”将出现在“Comp Engine %”之前，而“Comp Engine %”又会出现在“%”之前。 在上下文定义相同的情况下，本地配置优先于中央配置； 如果您希望 local 始终胜过central，即使在central 范围更紧密的情况下，您只需颠倒两个排序项的位置即可。

Answer 2

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