天儿真好,
我们有一个Perl脚本,负责处理来自主要网站的前端服务器的地理定位请求.该脚本是一个代理,提供额外的业务逻辑,解释由COTS产品返回的数据,该产品为给定的IP地址提供数据,例如国家,连接类型,路由类型,运营商等.
此Geo服务当前正处理COTS后端每秒约1,000个请求的峰值负载.BTW它实际上是从其专用的负载均衡/缓存层提供5,000个请求ps,它直接位于代理层之前.
我最近不得不修改这个代理的行为,以允许我们在网站上看到的新类型的连接,这会引起一些问题.
脚本的原始版本,不是我的设计!btw,是使用脚本本身中的配置项和单独的Perl片段中的其他项混合构建的.正如在我的更改的同行评审期间非常正确地指出的那样,我们应该将所有配置项迁移到单独的而不是继续混合使用嵌入式和单独的配置项.
现在我想更进一步,将所有配置项(作为单独的Perl哈希创建)放入一个配置文件中.
目前,我们必须停止并重新启动整个应用程序以重新加载新的配置项,考虑到流量水平,即使在两个独立的数据中心有四个代理实例,我们也不会真正丢失服务.
我怀疑我将不得不求助于保留计时器,或者可能是请求计数器,并对有问题的配置文件执行统计.或者甚至可以为配置文件配置一个TTL,并且每隔十分钟左右重新加载一次.
但有没有办法让Perl自动重新加载以前加载的文件的较新版本？我正在考虑Apache mod_perl模块提供的行为.
干杯,
Rob,几点:
1)优选地,将配置读取器抽象为API而不是直接从Perl散列读取.这样,对该API的任何调用都可以反过来决定需要对配置做什么(例如,计时器是否已启动？配置文件时间戳是否发生了变化？).
与往常一样,这有一个额外的好处,允许您稍后重新设计配置(perl has => xml => Database)而无需更改任何软件.
2)看到它是一个服务器,我还建议通过特殊请求类型按需配置重新加载功能.这允许您通过向服务器发送命令而不是反弹来强制配置重新加载(例如,在更新配置文件之后).
顺便说一句,#2非常容易,如果你遵循#1,因为"reload config"处理程序需要做的就是重置"config需要在下一个配置API调用上重新加载"标志.
3)如果您坚持将配置作为没有API的哈希(例如,出于性能原因消除API子程序调用,这似乎是合理的但不太可能有用),那么您需要将配置放入静态变量中class,并让该类提供"set new config"方法.然后服务器将设置一个计时器,并在计时器调用(或从#2接收"reload config"命令)时检查配置文件的时间戳和/或校验和是否与上次调用时不同并重新加载.
京公网安备 11010802040832号 | 京ICP备19059560号-6 