起因

午休后准备改个App的UI方面的bug，发现app接口好像有问题，看起来是服务器都挂了，测试环境有时候就是这么随意，这样想着，就切到了线上环境，发现服务器也是挂了的状态，行吧，休息会，喝点水

一二十分钟后线下接口正常了，没太在意

四点多的时候，听安卓的开发说有个问题，让帮忙确认一下，把网先断掉，然后再进去详情页，看看某个接口的调用情况，发现在这种情况下接口一直在高频调用，听说是因为这个原因导致服务器都挂掉了(这次是webview里的接口高频调用，非原生)

想起来在以前项目组也遇到2次这样的问题，一次是凌晨被电话叫起来排查问题，晚上折腾了一通，没排查出问题，那一块的代码都上线半年了也没啥问题，最近也没改动，第二天mock了当时的接口数据才排查出问题，是活动相关的代码，有个定时器轮询接口的场景，时间间隔原定不能为null，结果后端业务交接转了几手后当天晚上十二点上的活动还是有个配置为null了，还好有以前的接口wiki，不然真是跳进黄河也洗不清了；当时是通过修改服务端配置来临时规避问题，客户端也加了保护，避免下次配置时再次出现问题。

第二次是被别人坑了，或者算是沟通问题，有个场景说接口请求失败的情况怎么办，结论是重新请求直到成功，当时理解是失败后就再去请求，出了问题后再沟通，意思是让请求失败后提示用户重新刷新，点击刷新后再请求接口；因为是物流app，很多用户是在路上一直使用，网络不好的情况不在少数，结果就会出现网络不好接口请求失败后就疯狂请求的场景，当然可能也只是疯狂请求，但请求没有触达服务器，对业务没有实质的影响，但错误的日志最后都会上传到服务器，就是出现很离谱的错误率指标和告警信息。

一句话真因

客户端在异常场景存在短时间大量多次请求接口问题，把服务器打挂了

如何处理接口高频调用的问题

1. 客户端
   • 业务层，如果有存在接口请求重试，或者递归、循环请求接口的场景，务必注意异常场景，最好是每次请求之间设置最小时间间隔；加递归深度限制，比如最大层级10层，超过则中断递归。
   • 业务层，如果接口请求由按钮点击触发，需要添加防重逻辑
   • 请求层，用唯一标识(如URL+参数MD5等)做缓存，相同请求未响应时直接拦截
2. 服务端
   • 加校验，服务端识别重复请求ID后直接返回缓存结果。
   • 限流，根据用户Id、接口维度等限制每秒/N次请求。
   • 熔断降级，监控接口失败率，比如50%阈值，触发后直接返回缓存数据或者降级提示，避免服务雪崩