上一篇博文講到服務器端設置connections無效后，我再查詢了官方文檔，connections參數的定義為：“對每個提供者的最大連接數，rmi、http、hessian等短連接協議表示限制連接數，dubbo等長連接協表示建立的長連接個數”。我認為如果此參數並不是限制服務端的，那么這個參數很有可能是限制客戶端鏈接的。比方說connections=2時，每個客戶端只能創建兩條和服務器端的連接。那么我們就開始實驗吧：
完整代碼在 https://github.com/ralgond/dubbo-example/releases/tag/v0.0.4
修改dubbo-example-consumer的consumer.xml的dubbo:reference標簽成如下:
<dubbo:reference id="greetingService" interface="com.github.ralgond.de.sdk.GreetingService" group="dubbo" version="0.0.1"
timeout="30000" connections="2"/>
啟動dubbo-example-provider的com.github.ralgond.de.provider.ApiProvider2，為服務端。
啟動dubbo-example-consumer的com.github.ralgond.de.consumer.ApiConsumer2，為客戶端。
等待Console打印出“Hello world raglond”后在cmd執行：
netstat -aon | findstr "20880" | findstr "23724" | find /c /v ""
上面這段命令是在計算客戶端到服務端的真實的連接數，得到的結果是28。需要注意的是其中的“23724”是客戶端的進程號，你應該輸入正確的進程號，而不是23724。
到這里，我們通過不斷調整connections的數值，發現一個規律：
當connections=1時，連接數為14
當connections=2時，連接數為28
當connections=3時，連接數為42
當connections=10時，連接數為140
可見連接數是connections數值的14倍，而並非我們設置的數值。
為什么會是14倍呢？主要原因是provider注冊自己到zookeeper時使用的是持久節點，因為我之前啟動了14次的provider，那么ZK里的節點/dubbo/{serviceName}/privoders下面就會14個子節點，它們都是只向相同的主機，比如192.168.0.105:20880。
客戶端啟動后會從zookeeper拉取出會得到14個地址，盡管url非常相似（只有pid和timestamp不同），但它依然將結果視為14個不同的provider，也因此它會創建14條連接到偵聽192.168.0.105:20880的provider（connections等於1時）。