HTTP 調用超時、重試、並發?


http調用,走的是http協議,但網絡層走的是TCP/IP協議

所以一定是需要先建立連接的,所以存在兩個超時參數:

1、連接超時 ConnectTimeout , 配置用戶建立連接的最長時間

2、讀取超時 ReadTimeout ,控制socket 上讀取數據的最長等待時間

 

連接超時設置的比較長的問題,會導致一直在嘗試進行連接,創建大量的線程,最終崩潰

如果是客戶端直接連服務端,那連接超時大概率是服務端的問題

如果是經過了一層nginx , 那連接超時就要考慮nginx的問題了

 

讀取超時: 如果讀取超時,那服務端的執行會中斷 ?

其實類似tomcat的web服務器都把服務端請求提交到線程池處理的,只要服務端收到了請求,網絡層的超時與斷開便不會影響服務端的執行

所以讀取超時,並不能說明服務器那兒沒干事兒

大部分的讀取超時,可以認為是服務器業務邏輯的時間

大部分的連接超時,可以認為是網絡問題或者服務不在線

通常讀取超時設置不超過30秒

 

重試 get,head請求在瀏覽器上會主動進行重試

 

最終總結:

  誤區一 誤區二 概念  
讀取超時 讀取超時時,服務端的執行也停止
其實不是,服務端的線程池接收到任務,
網絡的情況就與實際服務端操作無關了
讀取超時設置越長服務的成功率越高?
客服端遇到服務超時,可能會受到拖累而創建
大量線程,最終崩潰
可以把讀取超時的時間大概率認為是服務端業務處理時間  
         
連接超時

連接超時設置很大
如果連接不上,一般就是網絡問題或者是
服務不在線,設置短一些反而可以快速失敗;
如果是純內網調用,更是應該設置更短

連接的是哪兒?

有的是客戶端與服務端直接連接,所以超時
可以直接服務端的服務情況;如果中間有nginx
就應該考慮nginx的問題了

   
         
重試機制 對於get,head請求一般都會有個重試機制
API的設計里,如果是get請求一般是無狀態的
如果有狀態的接口一般不定義為get

  如果進行重試,一定要保證服務的冪等性  
         
並發限制        
         
         

為啥沒有寫超時?

因為數據都寫入到TCP緩沖區,從緩沖區寫入到服務端,屬於本地的操作,不存在超時之說。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM