建站
咨詢
售后
建站咨詢
新聞中心
目錄
- 業(yè)務系統(tǒng)架構圖
- 微服務項目技術難點 1：RPC 的超時機制
- 微服務項目技術難點 2：RPC 的重試機制
- 生產(chǎn)項目中 timeout 和 retry 一般設置成多少呢?
今天給大家分享一知識點，是關于我們平時開發(fā)系統(tǒng)做 RPC 通信的時候，經(jīng)常會設置超時和重試兩個參數(shù)。
目前累計服務客戶上千，積累了豐富的產(chǎn)品開發(fā)及服務經(jīng)驗。以網(wǎng)站設計水平和技術實力，樹立企業(yè)形象，為客戶提供成都做網(wǎng)站、網(wǎng)站建設、網(wǎng)站策劃、網(wǎng)頁設計、網(wǎng)絡營銷、VI設計、網(wǎng)站改版、漏洞修補等服務。成都創(chuàng)新互聯(lián)始終以務實、誠信為根本，不斷創(chuàng)新和提高建站品質(zhì)，通過對領先技術的掌握、對創(chuàng)意設計的研究、對客戶形象的視覺傳遞、對應用系統(tǒng)的結合，為客戶提供更好的一站式互聯(lián)網(wǎng)解決方案，攜手廣大客戶，共同發(fā)展進步。
關于這兩個參數(shù)要是沒有設置好的話，很可能會導致我們的系統(tǒng)被搞垮，但是可能很多人都不知道這里面的問題，所以今天給大家好好講講。
業(yè)務系統(tǒng)架構圖
首先，我們還是先引出一個話題，那就是平時我們開發(fā)的系統(tǒng)是什么樣的?其實往簡單了說，就是用 SpringBoot+SSM 開發(fā)一套業(yè)務代碼，然后用 Nacos+Dubbo 去 RPC 調(diào)用別的系統(tǒng)。
這個架構圖非常簡單，如下所示：
微服務項目技術難點 1：RPC 的超時機制
那么在兩個系統(tǒng)進行 RPC 調(diào)用的時候，有兩個參數(shù)其實是至關重要的，一個是 timeout 超時時間，一個是 retry 重試次數(shù)，這個 timeout 超時通常用于什么場景呢?
大家可以想象一個場景，如果說我們不設置 timeout 超時時間，是否可能出現(xiàn)這樣一種情況，就是你調(diào)用的那個系統(tǒng)可能故障了，或者是掛了，或者是他的性能突然很慢很慢，導致你調(diào)用他好幾秒都沒法返回。
如下圖：
如果要是你調(diào)用一個系統(tǒng)時間很久都沒法返回，此時會導致什么問題?
我們要知道，你自己這個系統(tǒng)對外接收請求靠的是線程，假設我們是 通過 SpringBoot 內(nèi)嵌 Tomcat 對外接收請求的，那么其實 Tomcat 就會開很多線程，每個 Http 請求過來了，每個請求都是要交給一個線程來處理的。
如下圖所示：
那么一個線程拿到了一個請求開始處理之后，他就會去調(diào)用別的系統(tǒng)，如果要是調(diào)用別的系統(tǒng)這個過程中因為他故障了，導致調(diào)用時間超長，好幾秒都沒個響應，這個時候會怎么樣呢?
那還不簡單，這會導致 Tomcat 一個線程一直阻塞好幾秒都沒法去處理別的請求。那么這個時候，如果所有線程都因為調(diào)用一個服務被阻塞住了，是不是就導致新的請求過來沒有一個線程可以處理了?
如下圖：
所以說，往往來說，我們對于別的服務 RPC 調(diào)用一般都得設置一個超時時間，比如說，設置 timeout=1s，那么意思就是說，我們調(diào)用別的系統(tǒng)如果超過 1s 沒有響應，就直接拋個異常就返回了，這樣就可以避免我們的 Tomcat 線程 長時間阻塞了。
如下圖：
微服務項目技術難點 2：RPC 的重試機制
那么除了這個 timeout 超時時間以外，還有另外一個參數(shù)是 retry，這個 retry 的意思，就是說如果你 RPC 調(diào)用一個服務要是失敗了，此時就可以通過 retry 設置自動做一個重試。
比如說自動可以重試 2 次，那么這個時候如果是因為網(wǎng)絡偶然抖動導致的調(diào)用失敗，就可以通過重試 2 次讓他能夠成功完成調(diào)用了。
如下圖：
生產(chǎn)項目中 timeout 和 retry 一般設置成多少呢?
好了，現(xiàn)在 timeout 和 retry 兩個參數(shù)講完了，下面就可以講這兩個參數(shù)設置不當是如何導致系統(tǒng)出現(xiàn)故障的了。
先來說這個 timeout，這個 timeout 設置可一定要慎重啊，因為如果要是設置的不謹慎，可能導致你的系統(tǒng)莫名其妙就直接跨掉了。
比如說，這個 timeout 你要是設置的時間太長了，好比說 5s，10s，那么可能在極端情況下，比如對方系統(tǒng)故障了，你每個請求都要 5s、10s 才能返回，那不就會導致剛才上面說的問題了?
就是 Tomcat 每個線程都得阻塞 5s、10s 才能返回，這就導致你的系統(tǒng)沒法處理新的請求了。
如下圖：
那么如果要是 timeout 設置的太短了呢?比如說設置 timeout=500ms，那好，這可能也有很大問題了。
因為有可能某一天因為搞活動流量比較大，你調(diào)用的系統(tǒng)因為壓力比較大，導致他的 CPU 負載很高，然后平時一般請求都是 300~400ms 可以返回，結果今天搞成 500~600ms 了，剛好超過了 timeout 時間。
此時就會導致，你大量的請求即將處理完畢要返回的時候，結果一到 500ms 就超時異常拋出，一到 500ms 就超時異常拋出。
如下圖：
所以說，timeout 超時參數(shù)設置，通常是這么設置的，對于你要調(diào)用的系統(tǒng)你要看看他平時調(diào)用要多久能返回，然后比正常的耗時設置的多個 50% 就可以了。
比如平時一般正常在 100~200ms，偶爾高峰會在 500ms，那你設置個 timeout=800ms 或者 1s 其實都可以。
然后就是 retry 這個參數(shù)，這個參數(shù)也是不能胡亂設置的，尤其是對于一些調(diào)用別的系統(tǒng)寫入數(shù)據(jù)的接口。
如果你要是對別的服務的寫接口設置了 retry，就可能有這樣一種場景，某一次寫入接口可能耗時稍微長了一些，導致了超時出錯，結果你又 retry 再次重試寫入，就可能導致數(shù)據(jù)會有重復的問題。
所以說通常都建議 retry 參數(shù)對讀接口可以設置一下，但是對寫接口最好是不要設置。
好了，今天關于 RPC 超時和重試參數(shù)的分享就到這里了。
網(wǎng)站名稱：八張架構圖告訴你如何優(yōu)雅地設置RPC超時重試
文章分享：http://m.5511xx.com/article/dhjjcee.html
