服务端响应超时？

1. 问题描述

服务端响应超时，有什么方法解决？

系统响应超时泛指系统没有宕机，但是业务处理性能差，服务响应低效。通常原因也好理解：

1. 内部程序设计问题：例如数据库查询慢、单个进程占用资源太多、某些处理出现Bug（死循环、低效算法等）

2. 外部原因：业务量快速增长、远远超出预计；遭到黑客攻击如DDos；促销、特殊事件带来的用户量脉冲式爆发

处理思路：保证核心业务和绝大部分用户。

示例场景 1上游接口 TP99 超 3s 仍未返回处理结果。示例场景 2因网络异常无法连接到上游服务。2. 解决方案a. 降级：监控发现资源不足时，对非核心业务不分配资源，全力保证核心业务。例如新闻论坛只保证浏览用户，暂时关闭评论和转发入口，对购物流程只保留黄金流程的购物体验，降级优惠券等虚拟资产的使用。 操作上有：通过后门降级（需要单个单个操作）；通过独立设计的降级系统，触发降级指令（类似以前电信的Overload信令）。

b. 熔断：和降级主要针对内部处理能力不足的区别是，主要应对外部业务爆发或攻击。熔断机制实现的关键首先是有统一的API调用层；其次是阈值的设定。一旦启动，则将某项服务直接中断，该服务的API调用全部直接返回错误，如“活动太火爆”、“程序员小哥哥送货去了”之类的提示窗。

c. 限流：降级是从内部降低服务响应级别来做，限流则是从外部访问压力角度来说的。限制入口流量在系统访问能力内，超出的丢弃。常见的是基于请求限流（总累积请求数、时间内请求数）；基于资源限流（内部的连接数、线程数等）；实现途径上看有nginx请求限流、redis集中限流以及jvm内存限流等。

d. 排队：其实类似于限流。一般同时还会在入口提供等待页面“前面有XXX个用户在等待，预计还需要XXX分钟！”，舒缓一下用户心理，在排队过程中逐渐处理业务请求，达到限流削峰的目的。

作者：夕阳雨晴，欢迎关注我的头条号：偶尔美文，主流Java，为你讲述不一样的码农生活。