服務端響應超時，有什么方法解決？

1. 問題描述

服務端響應超時，有什么方法解決？

系統響應超時泛指系統沒有宕機，但是業務處理性能差，服務響應低效。通常原因也好理解：

1. 內部程式設計問題：例如資料庫查詢慢、單個進程占用資源太多、某些處理出現Bug（死循環、低效算法等）

2. 外部原因：業務量快速增長、遠遠超出預計；遭到黑客攻擊如DDos；促銷、特殊事件帶來的用戶量脈沖式爆發

處理思路：保證核心業務和絕大部分用戶。

示例場景 1

上游接口 TP99 超 3s 仍未返回處理結果。

示例場景 2

因網路異常無法連接到上游服務。

2. 解決方案

a. 降級：監控發現資源不足時，對非核心業務不分配資源，全力保證核心業務。例如新聞論壇只保證瀏覽用戶，暫時關閉評論和轉發入口，對購物流程只保留黃金流程的購物體驗，降級優惠券等虛擬資產的使用。 操作上有：通過后門降級（需要單個單個操作）；通過獨立設計的降級系統，觸發降級指令（類似以前電信的Overload信令）。

b. 熔斷：和降級主要針對內部處理能力不足的區別是，主要應對外部業務爆發或攻擊。熔斷機制實現的關鍵首先是有統一的API調用層；其次是閾值的設定。一旦啟動，則將某項服務直接中斷，該服務的API調用全部直接返回錯誤，如“活動太火爆”、“程式員小哥哥送貨去了”之類的提示窗。

c. 限流：降級是從內部降低服務響應級別來做，限流則是從外部訪問壓力角度來說的。限制入口流量在系統訪問能力內，超出的丟棄。常見的是基于請求限流（總累積請求數、時間內請求數）；基于資源限流（內部的連接數、線程數等）；實現途徑上看有nginx請求限流、redis集中限流以及jvm內存限流等。

d. 排隊：其實類似于限流。一般同時還會在入口提供等待頁面“前面有XXX個用戶在等待，預計還需要XXX分鐘！”，舒緩一下用戶心理，在排隊過程中逐漸處理業務請求，達到限流削峰的目的。

作者：夕陽雨晴，歡迎關注我的頭條號：偶爾美文，主流Java，為你講述不一樣的碼農生活。