线上故障-隐藏的定时器问题

发表于 更新于 本文字数： 529 阅读时长 ≈ 1 分钟
本文介绍关于线上故障-隐藏的定时器问题，包括使用场景、实现细节等，以提高关于线上故障-隐藏的定时器问题的效率。

最近线上接到一个严重问题，即我们的服务端疯狂的向另一个某SDK服务方发送心跳请求。排查后发现是没注意到的一个点造成的，其中与定时器有关，因此这里Mark下

问题情况

现状是一分钟/一个服务IP请求了超 4000次。实际上正常情况应该是5分钟只会报一次。

分析

整个排查过程还是比较简单/清晰的

  1. 心跳请求确认后是SDK本身在初始化实例对象时就会自动触发，我们的逻辑里没有任何关于心跳设置和心跳调用的logic，因此一定是初始化的逻辑问题
    • SDK类的构造函数中有setInterval逻辑
  2. 查询程序发现目前有4处初始化实例对象，其中1处是服务启动时初始化，而其它3处在API调用时触发，因此假如API调用次数足够的多，那么即会带来N个定时器
  3. 生产日志查看，相关API的调用频次上升也与另一个服务监测的数据时间点有关

OK，确定问题后，解决也很清晰，即去掉在API调用中进行实例化SDK对象的逻辑。我们这里根据实际情况应该维持单例，且是服务启动时初始化即可。

修复后，重新监测，发现正常了。

总结

  1. JS函数执行完毕会销毁相关对象但并不会销毁定时器，因此在调用开启定时器这种逻辑时，必须注意销毁逻辑。
  2. 如上这种调用某函数，存在隐藏的定时器logic会是个坑，这点需多加注意。