dubbo 長連接

@[toc]

dubbo://

Dubbo 缺省協議采用單一長連接和 NIO 異步通訊，適合于小數據量大并發的服務調用，以及

服務消費者機器數遠大于服務提供者機器數的情況。

反之，Dubbo 缺省協議不適合傳送大數據量的服務，比如傳文件，傳視頻等，除非請求量很

低。

Transporter: mina, netty, grizzy

Serialization: dubbo, hessian2, java, json

Dispatcher: all, direct, message, execution, connection

ThreadPool: fixed, cached

特性

缺省協議，使用基于 mina 1.1.7 和 hessian 3.2.1 的 tbremoting 交互。

連接個數：單連接

連接方式：長連接

傳輸協議：TCP

傳輸方式：NIO 異步傳輸

序列化：Hessian 二進制序列化

適用范圍：傳入傳出參數數據包較小（建議小于100K），消費者比提供者個數多，單一

消費者無法壓滿提供者，盡量不要用 dubbo 協議傳輸大文件或超大字符串。

適用場景：常規遠程服務方法調用

約束

參數及返回值需實現 Serializable 接口

參數及返回值不能自定義實現 List , Map , Number , Date , Calendar 等接口，只能用

JDK 自帶的實現，因為 hessian 會做特殊處理，自定義實現類中的屬性值都會丟失。

Hessian 序列化，只傳成員屬性值和值的類型，不傳方法或靜態變量，兼容情況

詳細查看官方文檔

問題

看過一篇博客 講解的是dubbotcp鏈接過多的情況

dubbo連接池爆滿

然后跟著實驗了一遍;

先看下有總共有4個提供者

提供者provider端口是18220;有若干個消費者;先不做額外操作；先看一下有多少個tcp長連接

netstat -an |grep 18220

結果可以看到有8個連接

1.將某個provider鏈接設置為10個，consumer不設置

啟動然后查看tcp鏈接數

netstat -an |grep 18220 | wc -l

顯示的結果為38;

之前是8個中有三個消費者是消費WeChatCommonFacade服務的；現在變成了38，明顯是多了很多個，這個多出來的是WeChatCommonFacade這個Provider跟它的消費者連接數，WeChatCommonFacade的消費者有三個

3*10=30個鏈接數了;

2.將一臺comsumer的連接數配置成5個

在之前的基礎上，我們把其中一臺ip為：..*.194 的consumer連接數改成5

再看看提供者的tcp連接數

總共有33個；少了5個，說明我們修改了consumer的連接數起作用了，以consumer為準了；

(至于194的連接數有6個不用在意，多出的那個tcp鏈接是另一個消費者消費了另一個提供者)

3.將consumer設置為懶連接 lazy=“true”

netstat -an |grep 18220 | wc -l

結果：28

又少了五個連接;因為這個服務沒有被調用，所以沒有建立起tcp鏈接；等第一次調用這個服務的時候就會建立起這個tcp的長連接的；所以lazy延遲連接有利于減少長連接數；

4.粘滯連接 sticky=“true”

粘滯連接用于有狀態服務，盡可能讓客戶端總是向同一提供者發起調用，除非該提供者掛

了，再連另一臺。

粘滯連接將自動開啟延遲連接，以減少長連接數。

5.actives="" 可建立連接數如果小于connections連接數的話tcp連接會一直嘗試建立連接

dubbo官網

如果訪問不了,去下面鏈接直接下載

dubbo文檔下載

Dubbo TCP/IP

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。