小编今天被实习生坑惨了。。。

昨天线上问题

昨天出了一个线上问题，今天又出了一个线上问题。

昨天出的一个线上问题。

监控开始报大量的异常pvlost，接口访问过来报500，就报pvlost了。

小编赶快登录到这个出问题的实例，上去手动curl了一下这个请求，发现登录这个实例手动去curl没啥异常信息。

返回是正常的200。连续curl了十几次都没问题。

奇了怪了。

昨天没排查出来就想着加点日志打印点日志看下。这个问题先和客户同步好结论，就准备今天加日志看下。

结果今天还没来得及加日志。。。

今天又出一个线上问题

又爆出来个线上问题，那再继续看下这个新的线上问题。

发现新上线的一个查询故障机房的功能不太好使。

现在线上有两个机房。A机房和B机房。

  • 当A机房的tsdb时序数据库有问题就去查询B机房的tsdb时序数据库。
  • 当B机房的tsdb时序数据库有问题就去查询A机房的tsdb时序数据库。

客户op会发现哪个机房有问题，就会往数据库mysql插入一条故障机房数据。

上图里面的 idcA 对应的时间段有故障。

目前整个架构里面有M服务和D服务查询tsdb时序数据库。

在D服务里面实现了这个查询故障机房的功能，就是查询数据库里面看看那个机房有问题，如果发现用户传的查询起止时间段和mysql数据库里面的idcA故障时间有交集，那么就说明A机房有故障就去读取配置文件中idcB机房的url查询idcB机房的tsdb时序数据。

由于D服务实现了，就用M服务去查询D服务，由于D服务的可承受查询能力不行，M服务的查询压力很大，所以M服务查询D服务的时候做了一层缓存。

这缓存服务代码写的真牛逼，搞出两个线上问题。

@Cacheable(value=”cacheManager”,key=”#root.method”)
publicStringgetMalfunctionStatus(longqueryStartTime,longqueryEndTime){

QueryDateDtoqueryDateDto=newQueryDateDto();
StringstartTime=String.valueOf(queryStartTime);
StringendTime=String.valueOf(queryEndTime);

queryDateDto.setStartTime(startTime);
queryDateDto.setEndTime(endTime);
StringmalfunctionStatus=””;
try{
malfunctionStatus =查询D服务的数据http调用。
}catch(Exceptione){
LOG.error(“requestdashboardfailed.e:{}”,e.getMessage());

}
returnmalfunctionStatus;
}

缓存分析

给getMalfunctionStatus 这个方法加了缓存，key是这个方法名字。假设传的参数queryStartTime：2022-05-17 10:00:00 queryEndTime 2022-05-17 12:00:00

假设这个时间段查询下游 D服务的http调用，返回是故障 状态

缓存时间失效是5分钟。

这5分钟内这个getMalfunctionStatus 这个方法返回的都是故障状态。

如果这5分钟内用户传的是参数queryStartTime：2022-05-17 12:00:00 queryEndTime 2022-05-17 14:00:00 查询时间段不一样，但是由于有缓存，这个返回的还是故障状态。

这缓存加了个寂寞。

加还不如不加。

不加起码能查询下游D服务是正确的返回结果，加了这5分钟内结果都是错的。。。

实习生给小编留大坑！

实习生牛X!

第二个坑

这个服务如果发现当前机房出现故障了。

就根据查询的下游D服务的状态发现故障了，需要切换查询机房的地址。

所以就在配置文件里面写了两个机房的地址，然后读取配置文件就行了。

由于最近用户使用了添加了故障机房，报大量接口返回500错误。

是配置文件这块切换机房的时候的没有端口。导致查询下游服务报500。

总结

之前还是对实习生太仁慈了，以后实习生的代码还是得好好看看，实习生拿着一天300的实习工资，写了一堆坑的代码，搞出两个线上问题，混了份大厂实习经历，拍拍屁股走人了，小编在这擦实习生的屁股。

难受。。。