為什么json-rpc的rpcclient不保持長連接，而是每次接受完數(shù)據(jù)就關(guān)閉
為什么json-rpc的rpcclient不保持長連接，而是每次接受完數(shù)據(jù)就關(guān)閉
2個回答
打賞
如果是長連接，就涉及到復(fù)用連接的問題。
?但是沒有很劃算的機制能確認(rèn)某個連接對應(yīng)的進(jìn)程是否空閑，如果將消息發(fā)給非空閑的rpc進(jìn)程處理，會導(dǎo)致請求處理延遲甚至積壓。
?
長連接的情況：
假設(shè)A B兩個進(jìn)程的rpcclient和rpc的1號進(jìn)程保持了長連接，A通過長連接向rpc1號進(jìn)程發(fā)送了請求，很不幸這個請求要執(zhí)行1秒的時間，這時候B通過長連接也向rpc1進(jìn)程發(fā)送了請求，那么這個請求就會排隊等待，等待A的請求處理完畢才能被執(zhí)行，也就是最差的情況不管B請求多塊都要等待1秒才能返回。如果這種請求積壓了很多，會導(dǎo)致某些請求排隊返回異常緩慢。
?
短鏈接的情況：
如果是短連接，當(dāng)A進(jìn)程向rpc發(fā)送一個請求后，只有空閑的進(jìn)程才會去認(rèn)領(lǐng)這個請求，假設(shè)是rpc1號進(jìn)程處理，耗時要1秒。這時候B進(jìn)程向rpc發(fā)送的另外一個請求，這個請求不會落在rpc1號進(jìn)程，會被其它空閑的進(jìn)程認(rèn)領(lǐng)處理，不會造成B請求的排隊延遲。
?
所以短鏈接雖然耗費了一些建立連接的資源消耗，換來的是系統(tǒng)更快速的運行。話說回來，短鏈接的性能消耗和業(yè)務(wù)消耗比起來一般可以忽略。如果你的業(yè)務(wù)消耗很小，處理速度極快(純內(nèi)存計算不涉及外部存儲)，可以采用長連接的方式與rpc通訊。
?
- 暫無評論
