API服务假死

目录​​​

背景描述

问题以及解决

1、OOM问题

2、假死

3、为什么是每天晚上挂？

4、接口慢sql很多而且频繁调用怎么办？

5、其他

总结

---

背景描述

 某项目现场，发现每天晚上服务会挂，不是OOM就是服务假死，拒绝连接请求。1、OOM，直接看日志服务挂掉了 2、服务假死，看服务日志，日志还在正常打印，但是所有请求都被拒绝

  

项目背景： 以前在别的项目现场，数据中台，使用API服务对外提供接口之前，都是对数据进行加工处理之后，API只需要查询简单sql，不涉及复杂业务，而且接口有每次请求最多返回1w条的限制。

   这个项目，在以前API服务做了定制。1、项目甲方，不会数据治理，不会对数据加工，API提供的服务是多个表多次联合查询的接口。2、项目甲方，把API服务接口当做数据同步工具，让我们去掉每次只返回1W条数据的限制。

问题以及解决

1、OOM问题

原因：查询日志，发现用户每页设置返回100w条数据，通过这个接口查询出的数据内存大小有12G,API服务总共就8G内存，直接OOM

解决：拿着有效证据，找甲方沟通，把每次接口请求最多1w条，加上。

2、假死

原因：单接口，用户自定义的查询sql，sql很慢，分钟级别。每个数据源，后端数据库线程池核心连接数只有10个，高并发情况，导致10个核心线程还没返回请求，后面的请求已经达到，导致服务假死

    解决：1、接口返回时间，做15秒限制，超时直接报错

               2、单接口并发做限制，每秒只接受5个请求

               3、其实最核心的解决方案，是推动甲方使用数据中台的离线、实时、集成工具，对数据进行加工，再发布API，否则上面的都不能完全解决问题。

3、为什么是每天晚上挂？

    原因：需要找甲方沟通，看看他们使用场景。他们把API当做数据同步工具

   解决方案：需要找甲方沟通，推动他们使用中台其他工具。如果不使用，问题解决不了。

甲方还没同意，所以问题未解决。。。。

4、接口慢sql很多而且频繁调用怎么办？

   用户写的自定义sql封装的接口，关联查询十几张大表，一个sql查询时间都是10秒以上。遇到这种情况怎么办？

方法：每个完整的sql，MD5生成唯一的码sqlId，弄一个表统计5秒以上的sql，如果下次sqlId出现，控制它的并发量，上一个结果没返回，下一个就不请求数据库，支持接口返回请等待

5、其他

可能还有别的原因，这个项目比较奇葩，天天都有新问题，以后补充

---

总结

 奇葩项目，说服不了甲方。那就只能保证自己服务不挂，做限流，做超时限制，做连接限制，做服务数据量限制。限制不轻易放开，如果用户发现自己都用不了，反向推动去做数据治理、数据加工