实习生跑路留了一个大坑，搞出2个线上问题，我被坑惨了
Posted 啊码
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了实习生跑路留了一个大坑，搞出2个线上问题，我被坑惨了相关的知识，希望对你有一定的参考价值。
小编今天被实习生坑惨了。。。
昨天线上问题
昨天出了一个线上问题，今天又出了一个线上问题。
昨天出的一个线上问题。
监控开始报大量的异常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") public String getMalfunctionStatus(long queryStartTime, long queryEndTime)
QueryDateDto queryDateDto = new QueryDateDto();
String startTime = String.valueOf(queryStartTime);
String endTime = String.valueOf(queryEndTime);
queryDateDto.setStartTime(startTime);
queryDateDto.setEndTime(endTime);
String malfunctionStatus = "";
try
malfunctionStatus = 查询D服务的数据http调用。
catch (Exception e)
LOG.error( "request dashboard failed. e: ", e.getMessage());
return malfunctionStatus;
缓存分析
给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的实习工资，写了一堆坑的代码，搞出两个线上问题，混了份大厂实习经历，拍拍屁股走人了，小编在这擦实习生的屁股。
难受。。。
实习生跑路留了一个大坑，搞出2个线上问题，我被坑惨了
小编今天被实习生坑惨了。。。
昨天线上问题
昨天出了一个线上问题，今天又出了一个线上问题。
昨天出的一个线上问题。
监控开始报大量的异常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") public String getMalfunctionStatus(long queryStartTime, long queryEndTime)
QueryDateDto queryDateDto = new QueryDateDto();
String startTime = String.valueOf(queryStartTime);
String endTime = String.valueOf(queryEndTime);
queryDateDto.setStartTime(startTime);
queryDateDto.setEndTime(endTime);
String malfunctionStatus = "";
try
malfunctionStatus = 查询D服务的数据http调用。
catch (Exception e)
LOG.error( "request dashboard failed. e: ", e.getMessage());
return malfunctionStatus;
缓存分析
给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的实习工资，写了一堆坑的代码，搞出两个线上问题，混了份大厂实习经历，拍拍屁股走人了，小编在这擦实习生的屁股。
难受。。。
以上是关于实习生跑路留了一个大坑，搞出2个线上问题，我被坑惨了的主要内容，如果未能解决你的问题，请参考以下文章