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個提供者

    <!-- dubbo服務釋出配置檔案 -->
    <dubbo:service interface="com.**.MenuFacade" ref="menuFacadeImpl"/>
    <dubbo:service interface="com.**.MaterialFacade" ref="materialFacadeImpl"/>
    <dubbo:service interface
 
="com.**.QrCodeFacade" ref="qrCodeFacadeImpl"/>
    <dubbo:service interface="com.**.WeChatCommonFacade" ref="weChatCommonFacadeImpl"  />

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

netstat -an |grep 18220

結果可以看到有8個連線

1.將某個provider連結設定為10個，consumer不設定

    <dubbo:service interface
 
="com.*.WeChatCommonFacade" ref="weChatCommonFacadeImpl" connections="10" />

啟動然後檢視tcp連結數

netstat -an |grep 18220 | wc -l

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

3*10=30個連結數了;

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

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

<dubbo:reference id="weChatCommonFacade" check="false" interface="com.*.WeChatCommonFacade" connections="5"  />

再看看提供者的tcp連線數

總共有33個；少了5個，說明我們修改了consumer的連線數起作用了，以consumer為準了；
(至於194的連線數有6個不用在意，多出的那個tcp連結是另一個消費者消費了另一個提供者)

3.將consumer設定為懶連線 lazy=”true”

<dubbo:reference id="weChatCommonFacade" check="false" interface="com.*.WeChatCommonFacade" connections="5" lazy="true" />

netstat -an |grep 18220 | wc -l
結果：28
又少了五個連線;因為這個服務沒有被呼叫，所以沒有建立起tcp連結；等第一次呼叫這個服務的時候就會建立起這個tcp的長連線的；所以lazy延遲連線有利於減少長連線數；

4.粘滯連線 sticky=”true”

<dubbo:reference id="weChatCommonFacade" check="false" interface="com.*.WeChatCommonFacade" connections="5" sticky="true" />

粘滯連線用於有狀態服務，儘可能讓客戶端總是向同一提供者發起呼叫，除非該提供者掛
了，再連另一臺。
粘滯連線將自動開啟延遲連線，以減少長連線數。

5.actives=”” 可建立連線數如果小於connections連線數的話tcp連線會一直嘗試建立連線

可以看到一直是TIME_WAIT狀態

dubbo官網
如果訪問不了,去下面連結直接下載
dubbo文件下載