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

前置知識(shí)點(diǎn)：rpc基礎(chǔ)，tcp基礎(chǔ)

rpc項(xiàng)目中的長(zhǎng)連接與短連接的思考

什么是rpc項(xiàng)目中的長(zhǎng)連接和短連接

和http的長(zhǎng)連接和短連接的概念類(lèi)似，rpc項(xiàng)目中的短連接是指處理完一次rpc請(qǐng)求后就斷開(kāi)連接，長(zhǎng)連接是指處理完一次rpc請(qǐng)求后不斷開(kāi)連接，復(fù)用連接。

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

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

與tcp和http的長(zhǎng)連接短連接的異同

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

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

這里也涉及一個(gè)平時(shí)很容易弄錯(cuò)的地方了，比如tcp的保活機(jī)制（keep-aliving?）與http協(xié)議的長(zhǎng)連接（Connection: Keep-Alive?）英文很相似，但是本質(zhì)上不是一個(gè)東西。

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

rpc連接的三種方式：

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

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

每類(lèi)連接模型沒(méi)有絕對(duì)好壞，取決于實(shí)際使用場(chǎng)景，一般來(lái)說(shuō)連接多路復(fù)用性能最好。

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

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

長(zhǎng)連接不是銀彈

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

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

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

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

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

使用長(zhǎng)連接的時(shí)候也需要考慮超時(shí)斷開(kāi)等機(jī)制。

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

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

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

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

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

L4 負(fù)載均衡器

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

??

這樣對(duì)RPC的影響是什么

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

L7 負(fù)載均衡器

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

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

??

L7均衡器無(wú)論是長(zhǎng)連接還是短連接都不會(huì)有L4在長(zhǎng)連接情況下的負(fù)載均衡的問(wèn)題，原因是因?yàn)長(zhǎng)7可以進(jìn)行HTTP協(xié)議的解析，從而可以在client無(wú)感知的情況下進(jìn)行切流。

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

因此使用長(zhǎng)連接還是短連接必須要根據(jù)實(shí)際情況來(lái)確定，不能無(wú)腦的選擇長(zhǎng)連接。

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

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

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

總結(jié)

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

而拋開(kāi)L4負(fù)載均衡來(lái)說(shuō)，現(xiàn)實(shí)中L7和胖客戶端的負(fù)載均衡一般來(lái)說(shuō)也是混合使用的，不會(huì)單獨(dú)使用。

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

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

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

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

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

最新評(píng)論