服務端響應超時？

1. 問題描述

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

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

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

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

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

示例場景 1

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

示例場景 2

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

2. 解決方案

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

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

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

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

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