代码之家 › 专栏 › 技术社区 › Rob Wells

使Perl脚本在单独的配置模块中检测更改,也在Perl中检测更改

configuration-files solaris perl

Rob Wells · 技术社区 · 15 年前

国庆节,

我们有一个Perl脚本,它正在处理一个主要网站中来自前端服务器的地理位置请求。该脚本是一个提供额外业务逻辑的代理,解释COTS产品返回的数据,该产品为给定的IP地址(如国家、连接类型、路由类型、运营商等)提供数据。

这个geo服务目前正在COTS后端处理大约每秒1000个请求的峰值负载。顺便说一句,它实际上为5000个请求提供服务,这些请求来自它的专用负载平衡/缓存层,该层直接位于代理层之前。

我最近不得不修改这个代理的行为,以允许我们所看到的在站点上发生的新类型的连接,这会导致一些问题。

脚本的原始版本,不是我的设计!btw是使用脚本本身中的配置项和单独的perl片段中的其他项的混合来构建的。正如在对我的更改进行同行评审时所指出的,我们可能应该将所有配置项迁移到单独的位置,而不是继续混合使用嵌入的和单独的配置项。

现在,我想更进一步,将作为单独的Perl散列创建的所有配置项放在一个配置文件中。

目前,我们必须停止并重新启动整个应用程序,以重新加载新的配置项,考虑到流量级别,这有点不方便,即使跨两个独立数据中心有四个代理实例,我们也不会真正失去服务。

我怀疑我将不得不使用一个计时器,或者一个请求计数器,并对有问题的配置文件执行一个stat。或者甚至可以为配置文件配置一个TTL,然后每隔十分钟左右重新加载一次。

但是,有没有一种方法可以让Perl自动重新加载以前加载过的文件的新版本?我正在考虑类似于ApacheModPerl模块所提供的行为。

干杯,

5 回复 | 直到 13 年前

DVK 15 年前

Rob,几点:

1)最好将配置阅读器抽象为API,而不是直接从Perl哈希读取。这样,对该API的任何调用都可以依次决定配置需要做什么(例如,计时器是否已启动)?配置文件时间戳是否更改?).

与往常一样,这还有一个额外的好处,即允许您稍后重新设计配置(perl has=>xml=>database),而无需更改任何软件。

2)鉴于它是一个服务器,我还建议通过一个特殊的请求类型提供按需配置重新加载功能。这允许您通过向服务器发送命令来强制重新加载配置(例如,更新配置文件后),而不是使其反弹。

顺便说一句,如果您遵循1,那么2非常容易完成,因为“reload config”处理程序只需要重置“config needs to be reloaded on the next config api call”标志。

3)如果您坚持将配置作为没有API的散列(例如,出于性能原因消除API子例程调用,这是合理的,但不太可能有帮助),那么您需要将配置放入类中的静态变量中,并让该类提供“set new config”方法。然后,服务器将设置一个计时器,在计时器调用时(或在从2接收到“reload config”命令时)将检查时间戳和/或配置文件的检查和是否与上次调用和重新加载时不同。

Adam Flott 15 年前

如果您使用的是最新版本的Linux,那么总会有一种不完善的方法。这意味着您可以在配置写入磁盘后立即重新加载它。退房 Linux-Inotify . 也有 FAM 其他平台。

Tim Palak Chaudhary 15 年前

在Unix类型的机器上解决这类问题的传统方法是,服务器程序在收到 signal . 例如, Apache documentation 表示这三个信号对服务器有特殊意义:term告诉服务器关闭,hup强制立即重新启动,usr1请求优雅地重新加载配置文件。如果您在一个支持信号的环境中工作,这种功能可以相对直接地构建到您的程序中。

Howard Hart 15 年前

始终可以选择将配置移动到数据库中,并使用DBI Plus数据库触发器使其成为事件驱动的,而不是轮询的。

Rob Wells 15 年前

@dvk,噢,用你的观点说得很好1)我没有想过在配置上面添加额外的抽象层。我想把它保留为原始Perl散列的好处是不需要转换层。我会考虑一下其中的权衡。

关于第2点),我们发现Perl中的一些信号处理的薄片使得它不能很好地进行hup,因此我们在站点范围内正式否决了Perl信号hup。

但我真的很喜欢你的想法,一个特殊的查找命令,将迫使重新加载!如果你不介意的话,我就用这个。也许可以使用“GET 127.0.0.1”,因为它可能不会从外部通过!注意:我们最新版本的地理协议是基于HTTP的,因此我们可以从浏览器轻松查询服务。

谢谢! \o/