對于rpc項目，在接受大佬指導(dǎo)的時候曾問過對于長連接和短連接是如何處理的，在面試的時候也被問起socket?是長連接還是短連接，發(fā)現(xiàn)自己沒有好好思考過這個問題，因此好好總結(jié)一下。

前置知識點：rpc基礎(chǔ)，tcp基礎(chǔ)

rpc項目中的長連接與短連接的思考

什么是rpc項目中的長連接和短連接

和http的長連接和短連接的概念類似，rpc項目中的短連接是指處理完一次rpc請求后就斷開連接，長連接是指處理完一次rpc請求后不斷開連接，復(fù)用連接。

甚至很多rpc的底層實現(xiàn)就是http協(xié)議，因此長連接和短連接很類似就不足為奇了。

http中長連接是指處理完一次http請求和響應(yīng)之后不斷開tcp連接；http短連接是指處理完一次http請求和響應(yīng)之后斷開tcp連接（需要注意的是：一般是服務(wù)器斷開，至于為什么是服務(wù)器斷開，則又是一篇小文章了hhh）。

與tcp和http的長連接短連接的異同

?rpc?和http?的長短連接的異同上文已經(jīng)分析過了，本質(zhì)上沒什么區(qū)別，都是控制?tcp?的斷開時機。
而tcp長連接平時聊的很少，很多人甚至不清楚tcp也是有“長連接”機制的，其名字叫做 tcp的保活機制（keep-aliving），其會在長時間沒有信息交流的時候向?qū)Χ税l(fā)送探測報文，并且在一定次數(shù)沒有回復(fù)后就斷開連接。

tcp的?；顧C制與現(xiàn)在常見的探測機制非常相似（服務(wù)探活、rpc探活等），但是大家基本都沒有采用tcp的?；顧C制，而是采用自己的保活機制，原因在于tcp?；顧C制的探測時間太長了，在默認(rèn)設(shè)置下，2個多小時才能探測出對端已經(jīng)掛掉，具體見：淺談 tcp ?；顧C制

這里也涉及一個平時很容易弄錯的地方了，比如tcp的?；顧C制（keep-aliving?）與http協(xié)議的長連接（Connection: Keep-Alive?）英文很相似，但是本質(zhì)上不是一個東西。

客戶端與服務(wù)器有哪幾種連接模式與利弊分析

rpc連接的三種方式：

常規(guī) RPC 的連接模型主要有三種：

短連接：每次請求都創(chuàng)建新連接，得到返回后立即關(guān)閉連接 長連接池：單個連接可以處理多個請求和返回，但同時只能處理一次完整請求與返回 連接多路復(fù)用：單個連接可以同時異步處理多個請求與返回

每類連接模型沒有絕對好壞，取決于實際使用場景，一般來說連接多路復(fù)用性能最好。

這些應(yīng)該是一些比較成熟的rpc框架實現(xiàn)的，中間配有負(fù)載均衡器才能實現(xiàn)連接池的操作。

如果是客戶端與服務(wù)端直連，本質(zhì)上就是兩種：長連接和短連接。

長連接不是銀彈

本節(jié)主要說明長連接雖然相對于短連接一般情況下性能好，但是不是十全十美，必須有所考量。

1. client 和 server 的數(shù)量

?rpc?長連接模式下相比于rpc?短連接，在相同client?數(shù)量的情況下，需要維系的連接數(shù)更多（連接一般不會斷開，或者是需要超時或者是其他情況才會斷開），因此當(dāng)client?數(shù)量相比于server數(shù)量過多的時候，使用長連接會有以下幾個問題：

?server?需要維護數(shù)量眾多的連接，壓力很大。 端口很容易耗盡

因此在client?數(shù)量特別多的情況下就不適合用長連接了，用短連接反而合適一些。

使用長連接的時候也需要考慮超時斷開等機制。

所幸rpc?服務(wù)器一般來說client?的數(shù)量相比于網(wǎng)頁服務(wù)器等會少很多，因此使用長連接應(yīng)該就可以了。

2. 負(fù)載均衡機制

現(xiàn)代后端服務(wù)端架構(gòu)中， 為了實現(xiàn)高可用和可伸縮， 一般都會引入單獨的模塊來提供負(fù)載均衡的功能， 稱為負(fù)載均衡器。根據(jù)工作所在的OSI?層級的不同， 不同的負(fù)載均衡器會提供不同的轉(zhuǎn)發(fā)功能。

不同的均衡器是根據(jù)工作在OSI?的層級進行區(qū)分的，以最常見的 L4負(fù)載均衡器(工作在 TCP?層）和 L7負(fù)載均衡器(工作在應(yīng)用層， 如HTTP?）兩種負(fù)載均衡器來舉例分析這兩種負(fù)載均衡器對與rpc的影響。

當(dāng)然，不一定需要一個單獨的一個組件來完成負(fù)載均衡，實際上，很多項目中都是采用直接在客戶端進行負(fù)載均衡的操作（胖客戶端）來避免引入單獨的負(fù)載均衡器。

L4 負(fù)載均衡器

L4工作在TCP層，就是對TCP的流量進行負(fù)載均衡的轉(zhuǎn)發(fā)，由于TCP的特性，因此L4的負(fù)載均衡器并不能知道某次rpc請求是否處理完畢，只是在發(fā)起請求的時候進行負(fù)載均衡處理（選擇要轉(zhuǎn)發(fā)到哪個服務(wù)器上）。

??

這樣對RPC的影響是什么

如果rpc是長連接：長連接情況下client?會一直保持和某個server?的連接，這樣的話在client與server建立連接之后負(fù)載均衡就失效了。但是新的?client?連接進來的時候還是會負(fù)載均衡的。這樣容易導(dǎo)致在client?數(shù)量很少的時候會導(dǎo)致流量分發(fā)不平均：? 如果rpc是短連接：每次請求都會重新連接，因此每次都會負(fù)載均衡。

L7 負(fù)載均衡器

L4負(fù)載均衡在長連接情況下導(dǎo)致負(fù)載均衡在某種意義下失效的本質(zhì)原因是負(fù)載均衡器在第一次連接的時候負(fù)載均衡后，后續(xù)不會再負(fù)載均衡了。

相比 L4 只能基于連接進行負(fù)載均衡， L7 由于在HTTP層進行負(fù)載均衡，其可以進行 HTTP? 協(xié)議的解析。當(dāng) client 發(fā)送請求時， client?會先和 L7 握手， L7 再和后端的一個或幾個 server? 握手，并根據(jù)不同的策略將請求分發(fā)給這些server?，從而實現(xiàn)基于請求的負(fù)載均衡。

??

L7均衡器無論是長連接還是短連接都不會有L4在長連接情況下的負(fù)載均衡的問題，原因是因為L7可以進行HTTP協(xié)議的解析，從而可以在client無感知的情況下進行切流。

這也是大家最廣泛使用的負(fù)載均衡的手法！

因此使用長連接還是短連接必須要根據(jù)實際情況來確定，不能無腦的選擇長連接。

關(guān)于tcp一些其他層面的優(yōu)化

即對socket? tcp?編程的優(yōu)化，我們可以考慮如下兩個方向：

?TCP_NODELAY?：禁用 Nagle? 算法，使小數(shù)據(jù)包能夠及時發(fā)送。 ?TCP_QUICKACK?：啟用 quickack? 模式，減少應(yīng)答延遲。

總結(jié)

從本文可知，rpc的負(fù)載均衡實現(xiàn)主要有3種：胖客戶端、L4層負(fù)載均衡、L7層的負(fù)載均衡，在現(xiàn)實中，L4層的負(fù)載均衡器一般用于中央交換機這樣的裝置，因此后端開發(fā)的同學(xué)一般是不會接觸到的。

而拋開L4負(fù)載均衡來說，現(xiàn)實中L7和胖客戶端的負(fù)載均衡一般來說也是混合使用的，不會單獨使用。

比如說一個經(jīng)典的集群維度的負(fù)載均衡示例圖如下：

一般來說至少有2層的負(fù)載均衡，分別保證集群維度的高可用和集群內(nèi)部服務(wù)的高可用。

集群維度的負(fù)載均衡用于保證集群維度的高可用：一般采用胖客戶端的方式，選擇一個固定的集群進行連接使用，除非當(dāng)前集群出現(xiàn)問題，否則一般不會切換。 集群內(nèi)部服務(wù)的負(fù)載均衡用于保證服務(wù)內(nèi)部的高可用：一般會使用L7的負(fù)載均衡器（如NGINX）進行轉(zhuǎn)發(fā)。通常情況下客戶端與負(fù)載均衡器的長短連接由于客戶端決定，而負(fù)載均衡器與服務(wù)器之間采用長連接以避免tcp握手，提高響應(yīng)速度。

無論是哪種維度的高可用保證，本質(zhì)上都是為了防止“單點”問題。

到此這篇關(guān)于關(guān)于rpc長連接與短連接的思考記錄的文章就介紹到這了,更多相關(guān)rpc長連接與短連接內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論